TSF微服務治理實戰系列(二)——服務路由
導語
在服務實例數量和規模較大的業務場景下,服務路由是系統比較常見的訴求,比如針對業務屬性的全鏈路灰度、測試環境多分支路由、多Region多AZ時的就近路由等。TSF基於標籤化能力完成流量染色和標籤自動傳遞,僅通過控制枱配置即可實現服務路由、全鏈路灰度及就近路由功能,快速滿足客户的業務分流訴求。服務路由從行為上講,是將流量進行染色區分,並通過路由規則將流量進行分流,本節將對TSF整體服務路由相關能力進行詳細介紹。
作者簡介
崔凱
騰訊雲 CSIG 微服務產品中心產品架構師
多年分佈式、高併發電子商務系統的研發、系統架構設計經驗,擅長主流微服務架構技術平台的落地和實施,目前專注於微服務架構相關中間件的研究推廣和最佳實踐的沉澱,致力於幫助企業完成數字化轉。
治理路由
功能説明
本文中“治理路由”特指TSF中的“服務路由”功能,主要為了區分廣泛意義上的服務路由。治理路由的配置參數包括:
-
流量來源配置:標籤類型、標籤名、邏輯關係、值
-
流量目的地:所在應用、目的地類型、部署組/版本號、權重。
簡單總結:通過判斷請求中標籤(key)對應的值(value)是否符合治理規則的配置,進而通過配置的權重比例將請求轉發到指定的部署單元,如不同的部署組或版本。
配置過程中需注意如下情況:
-
填寫治理路由規則需要在服務提供方進行配置,例如A服務調用B服務,需要在B服務上配置治理路由規則。
-
對於Spring Cloud服務,配置治理路由規則後,若配置的目標部署組無法運行,流量將按照原有默認的輪詢方式分配到其他部署組上。
-
對於Spring Cloud服務,當服務提示未綁定應用時,需要在服務詳情頁單擊編輯後綁定服務,才能開始配置治理路由規則。服務綁定應用操作,一經綁定,不能修改。
-
要使治理路由規則生效,需要確保在控制枱開啟了待生效規則,並在代碼中添加了路由的註解。
-
對於Mesh應用,配置路由規則後,若配置的目標部署組無法運行,則路由規則配置失敗,請求無法發送。
-
配置生效後,可以在列表項的流量分配圖中查看流量分配情況,如下圖所示。此時注意,配置了流量的權重比例後,要使路由準確性達到預期,請求數至少要在1000以上;如果請求樣本數不高的情況下偏差會比較大,樣本數越高準確性就才越高。
容錯保護
在使用治理路由時,TSF還具有容錯保護的功能來規避一些場景。假設針對provider服務分配了兩個版本:V1版本承載10%的流量,V2版本承載90%的流量,並針對上述流量分配進行了對應的治理路由的配置。此時,如果V1版本所有實例全部故障,那麼就會有10%的流程報錯,這是業務不能接受的。
此時可以使用容錯保護功能,當在provider服務的治理路由界面打開容錯保護功能時,TSF-SDK發現V1版本的所有實例都不可用,會嘗試將流量路由到目前所有可用的實例上(即V2版本的所有實例)。待V1版本實例從故障中恢復,容錯保護無需手動干預,即可將流量重新按照V1版本10%+V2版本90%的比例分配。
適用場景
治理路由能力從上述功能描述可以發現,它更着重對於單個或少數服務的路由進行管控,且對上下游服務的自定義標籤傳遞沒有強訴求,因為治理路由可以使用TSF系統標籤做判斷。所以,治理路由更適合少量串聯服務並需要單獨配置的路由場景。
測試環境多分支場景
往往客户資源有限的情況下,只有一套測試環境。當該環境正在進行feature版本的開發及測試時,如果突然需要修復生產環境的一個重要BUG,且當天上線這個hotfix版本。那麼測試人員需要把hotfix版本涉及的服務重新發布,並覆蓋現有測試環境中正在測試的feature版本。並且在hotfix版本上線後,將feature版本重新發布到原有資源上。除了資源替換產生的額外成本,還會產生版本覆蓋前後記錄上下文、更換環境配置等額外成本。
那麼我們如何解決呢?我們可以通過在測試環境創建hotfix版本的部署組資源並完成部署,同時通過治理路由規則+標籤化參數的方式,使得添加“feature”參數的請求調用feature分支服務,添加“hotfix”參數的請求調用hotfix分支服務,實現測試環境多分支並行測試的目的。在最終測試完成hotfix版本後,直接釋放hotfix分支使用的資源即可,不再需要進行版本替換和上下文更新,極大節省運維成本、提高測試效率。
配置步驟:
-
測試請求需在Path、Query、Header或Cookie中任一位置攜帶tag參數,指定分支版本信息(feature或hotfix)。
-
在微服務網關中新建Tag插件,配置Tag轉換規則,並將Tag插件綁定網關分組。
-
新建Service B、Service C的hotfix版本部署組,並完成應用發佈。
-
在Servcie B及Service C的服務治理->服務路由中新建路由規則,保存並開啟。
當在控制枱開啟治理路由規則時,規則會對應用實時生效。通過上述步驟即可快速實現測試環境多分支的治理路由配置。另外,假設Service C關聯了更多的版本/部署組(如4個),則只需針對Service C進行路由規則的添加即可,並不影響Service B的路由配置。
全鏈路灰度
功能説明
隨着系統架構向微服務轉變,應用的發佈頻率和次數都明顯增高。尤其當微服務的規模越來越大,如何能夠在保證低運維成本、故障爆炸半徑可控的情況下,完成全鏈路大規模的發佈動作,成為研發及運維部門面臨的難題。
全鏈路灰度是軟件逐步上線常用的發佈方式,是指將具有一定特徵或者比例的流量,逐步分配到指定版本的過程,通過生產流量實測發現新版本可能存在的潛在問題,同時將故障損失控制在灰度範圍內。
相比全量上線,灰度發佈是更加謹慎的發佈形式。當線上調用鏈路較為複雜時,全鏈路灰度發佈可以將生產環境隔離出一個邏輯獨立的運行環境。同時,全鏈路灰度的泳道可以反覆使用,即使進行變動也比較靈活,使得全鏈路灰度的運維成本也縮小很多。
使用全鏈路灰度發佈之前,需要先配置泳道。一條泳道相當於一個灰度環境,環境中包含應用中需要進行灰度測試的部署組。
泳道:泳道是一組業務關聯的部署組的集合,是灰度流量的目的地。泳道中的部署組屬於不同的應用,可以認為用户通過劃分泳道而劃分出了灰度環境。
灰度規則:用户新建灰度規則以設定灰度流量應滿足的條件。當灰度規則判斷請求滿足條件後,會通過灰度規則將流量路由到某一個泳道中。
泳道入口 : 在全鏈路灰度發佈模塊中發佈灰度規則時,會在泳道的入口部署組上對請求進行灰度規則校驗,以此來判斷請求是否應該進入某一個泳道中。泳道入口可以是一個微服務網關,也可以是一個微服務。
同一個泳道中支持多個入口,在請求經過每一個入口部署組時,都會判斷請求是否應該進入泳道中。
TSF全鏈路灰度發佈的操作流程如下圖,詳細操作步驟可瀏覽TSF官網進行查閲。http://cloud.tencent.com/document/product/649/43463
全鏈路灰度流量流向規則與説明
-
當泳道上已經綁定了全鏈路灰度發佈的規則,則不能刪除泳道。
-
當 請求流量沒有命中任何灰度規則,流量將走到沒有被添加到泳道的部署組中。
-
當某一個微服務下的部署組沒有被加入任何泳道中,請求將在該微服務下所有部署組的所有實例中輪詢。經過該微服務後,請求將繼續按照規則流入對應泳道。
-
一個部署組可以屬於多個泳道。
-
在泳道中,服務路由規則不生效。
-
泳道是一個隔離環境。 當泳道上所有規則關閉後,流量不會進入泳道中。如希望恢復建立泳道前的流量分配方式,請將泳道刪除。
全鏈路灰度中消息主題染色
kafka作為主流的消息隊列產品之一,經常用做業務邏輯間的解耦及大數據場景。那麼在全鏈路灰度發佈時,服務間調用如果使用了kafka做異步解耦,在消息未被染色時就會出現Consumer錯誤的消費了其它泳道消息的現象,這是業務不能接受的。
TSF通過將泳道標記在線程中向下傳遞的方式實現消息染色,即染色流量能在流經kafka後被對應泳道中的部署組消費,而未染色消息被不在任何泳道中的部署組消費,並且泳道標(即LaneId)能在消息流經kafka後繼續傳遞給下游服務。詳情請參見官網最佳實踐:http://cloud.tencent.com/document/product/649/75454
適用場景
全鏈路灰度發佈是大規模微服務架構場景下幾乎必備的發佈方式,它可以滿足指定小流量驗證、逐級切流控制故障範圍、多個關聯服務一次性共同發佈、一次配置反覆使用等要求,有效減少了發佈成本及上線變更帶來的風險。
基於地域和用户的灰度測試場景
互聯網產品經常會邀請公測用户進行體驗,當產品需要上線新功能時,希望使用灰度發佈的手段在小範圍內進行新版本發佈測試。在測試一段時間後,逐步的增加新版本的流量比例,同時減少原有版本的流量比例。上述這種灰度發佈的模式,不同於以往新舊版本發佈的一次性切換,讓整個發佈過程通過灰度發佈的方式進行過渡。
通過TSF進行如上場景的全鏈路灰度發佈流程步驟如下:
1、創建並部署微服務網關;
2、創建全部待灰度部署組併發布;
3、創建微服務網關分組、導入API併發布分組;
4、新建微服務網關插件並綁定分組;
5、新建泳道,並在泳道中添加全部灰度部署組,並設置網關為泳道入口;
6、創建灰度發佈規則並設置為生效狀態
根據如上配置,當用户發起的請求包含region=beijing、usertype=testUser的參數(代表北京地區的公測用户)時,則會進入所配置泳道部署組,實現全鏈路灰度的發佈操作。
同時在配置及運維過程中需注意:
1、評估單個provider服務實例可以處理多少請求,並根據流量分配來規劃部署組的實例數量。
2、如果流量比例變化後,可能需要調整部署組的實例數量來滿足新的流量。
3、可以通過設置彈性伸縮規則來支持動態調整實例數量。
4、全鏈路灰度發佈支持同時生效多條規則,並支持為規則配置優先級。當同一條請求同時滿足多條規則時,會優先匹配高優先級的規則。
單元化
功能説明
單元化架構主要是為了解決多中心容災、機房彈性擴容等問題,也可以依託單元化架構實現單元級故障隔離、單元級全鏈路灰度。本質上講,單元化架構也是流量路由的一種方式,只不過路由的目的地是每一個平行的業務自閉環的單元(Set)。
如下為兩地三中心架構下TSF單元化最佳實踐的簡要説明:
方案説明
1、基於智能DNS解析實現域名到地域的IDC機房路由,入口通過調整DNS解析結果,實現跨地域流量切換。
3、接入路由到應用,基於網關的標籤化路由實現單元服務路由規則匹配。
注意事項
1、單元內服務調用盡量在單元內閉環,減少跨單元調用。
2、如果業務需要跨單元調用,由微服務網關管理跨單元請求的轉發。
3、業務南北向流量應儘早完成正確單元的路由尋址,出現單元尋址錯誤時需能夠正常重定向。
4、當出現單元化路由KEY不符合任何單元或訪問不攜帶KEY時,可報錯或按默認單元化規則處理。
5、針對正常/錯誤的單元化調用流向,做到可監控、可預警、可管理。
TSF單元化能力主要以 “微服務網關”+“命名空間” 為實現基礎。微服務網關主要的作用是單元化規則的路由轉發,為了完成這一目的,TSF深度增強了開源微服務網關Zuul及SCG;命名空間是TSF本身具備的能力,分為普通命名空間和全局命名空間,普通命名空間主要用來對服務間調用進行邏輯隔離,全局命名空間主要用於打通特殊的跨普通命名空間的服務調用
在TSF單元化部署架構中主要使用全局命名空間放置微服務網關,使得微服務網關可以連通多個邏輯單元(普通命名空間)中的服務並進行單元化路由,使用普通命名空間進行各邏輯單元(Set)的隔離,保證每個單元的獨立。
單元化改造主要涉及兩個步驟:配置單元化、單元化部署,詳見官網鏈接。
-
配置單元化:http://cloud.tencent.com/document/product/649/55877
-
單元化部署:http://cloud.tencent.com/document/product/649/55879
適用場景
單元化適用場景主要集中在大規模或超大規模的分佈式系統中,同時從企業成本和管理角度講,整個單元化改造的過程是漫長的、成本是巨大的,實際情況可能是企業內部系統架構在擴展性、可用性、性能存在多方面痛點,不得不通過單元化改造來解決現有問題。
銀行業務單元化改造場景
單元化改造中單元化規則的設計是重中之重,且銀行業務一般情況不涉及到地域等其它屬性,所以主要還是從用户的業務屬性出發進行設計。
首先以用户ID尾號為單元化KEY,將用户劃分為00-99等量的100個數據單元,此為第一層全局分片規則。而後基於各產品線業務分片需求自定義二層分片規則,如對公對私場景,以用户ID前添加的公/私前綴字符串為KEY進行二次路由計算。通過上述規則設計,實現基於 全局+產品線 雙維度的單元化規則模型。
例如,假設用户標籤tag值為:B_20210817,一層標籤根據用户ID尾號的“17”進行全局分片路由,二層標籤根據對公對私的業務標記“B”(B為對公,P為對私)進行產品線分片路由,最終得出唯一的單元編碼(命名空間ID)。
確定單元化規則後,如上述《功能説明》中對微服務網關及相關單元化服務進行代碼修改,並按照流程在TSF控制枱操作創建單元化規則,即可完成業務的單元化改造。
TSF單元化架構核心價值體現在運維及開發成本、管理效率、高可用容災、彈性伸縮方面,對比客户自建單元化架構具備運維簡單、可用性高、開發便捷、配置靈活的特點,且可與TSF平台本身在諸多功能上進行聯動。
對比項 |
TSF單元化架構 |
自建單元化架構 |
運維成本 |
由TSF統一運維,提供企業級SLA支持 |
需企業自身具備較高運維水準 |
開發成本 |
無需開發單元化服務,通過控制枱配置實現 |
需企業自實現單元化服務 |
管理效率 |
與TSF整體Paas技術平台統一提供可視化管理,減少跨平台操作 |
代碼、配置平台、運維平台等多方面聯動管理,無統一可視化界面 |
高可用及容災 |
依託TSF多年高可用容災經驗積累,拒絕踩坑 |
需逐步完善自身高可用技術及人才 |
彈性擴縮 |
快捷聯動TSF自身基於容器、虛機的彈性伸縮和路由機制 |
需要自身配置實現彈性擴縮容機制 |
就近路由
功能説明
就近路由主要解決在同城雙活或多活場景下,應用在不同AZ有多個宂餘部署組時,當某一AZ的應用部署組實例全部故障後,通過就近路由可以自動切換到另外AZ的宂餘部署組中。同時,當部署組沒有出現故障時,我們會優先訪問同AZ的的被調服務,以減少跨AZ的訪問延時。通過就近路由可以在保證低延時的同時,提高一定的系統高可用性。
其功能配置比較簡單,即在創建命名空間後開啟即可(默認開啟)。
就近路由的實現主要依託於多個不同AZ的實例是註冊在同一套註冊中心上,通過consumer和provider服務在註冊時上報的信息,我們可以知道實例的所屬AZ、Region和部署組版本等信息,TSF-SDK會通過這些信息篩選最合適的實例進行調用。
通過上圖可觀察到,TSF-SDK會優先判斷被調服務是否有實例與主調服務在相同AZ內,如果沒有則會對規則降級,繼續判斷被調服務是否有實例與主調服務在相同Region內,直到最終找到符合就近路由規則的實例。
適用場景
就近路由主要使用在跨可用區容災場景下,如在廣州一、二區搭建同城雙活架構,當開啟就近路由時,廣州一區的consumer會優先調用同一可用區的provider。
此時,當廣州一區的provider不可用,consumer會跨可用區調用廣州二區的 provider。
更多詳細配置請參見:http://cloud.tencent.com/document/product/649/33797
結語
路由主要是解決流量如何分類,以及從哪裏來、到哪裏去的問題,本節通過對治理路由、全鏈路灰度、單元化、就近路由的功能及實踐場景的描述,展示了TSF在流量路由方面的核心能力,基本覆蓋了主要的流量路由場景,希望能給讀者朋友提供一點幫助。
引用
http://cloud.tencent.com/developer/article/1891503
http://cloud.tencent.com/document/product/649

One more thing
近日,Spring Cloud Tencent 於6月14日正式對外開源,作為騰訊開源的一站式微服務框架,Spring Cloud Tencent 實現了 Spring Cloud 標準微服務 SPI ,開發者可以基於 Spring Cloud Tencent 快速開發 Spring Cloud 微服務架構應用。Spring Cloud Tencent 的核心依託騰訊開源的一站式服務發現與治理平台 Polarismesh ,實現各種分佈式微服務場景。
-
如果你也是 Spring Cloud 的愛好者
-
如果你的公司正在使用 Spring Cloud 並且有一些好的實踐
-
如果你的公司正在做微服務技術選型
... ...
請加入我們,你的一個建議、Issue、Pull Request 甚至只是一個小小的 Star 都是對我們最大的支持,也是我們持續迭代的動力。
Github 地址(文末點擊「閲讀原文」即可跳轉至該鏈接):
http://github.com/Tencent/spring-cloud-tencent
掃碼進Spring Cloud Tencent用户交流羣
往期
推薦
掃描下方二維碼關注本公眾號,
瞭解更多微服務、消息隊列的相關信息!
解鎖超多鵝廠周邊!
戳原文,查看更多微服務平台TSF的信息!
點個 在看 你最好看
- Apache Pulsar 技術系列 - Pulsar 總覽
- 解決創新業務的三大架構難題,央廣購物用對了這個關鍵策略
- 詳解 Apache Pulsar 消息生命週期
- 8年服務百萬客户,這家SaaS公司是懂雲原生的
- 基於騰訊雲微服務引擎(TSE) ,輕鬆實現雲上全鏈路灰度發佈
- 騰訊雲基於 Apache Pulsar 跨地域複製功能實現租户跨集羣遷移
- 面向異構技術棧和基礎設施的服務治理標準化
- Pulsar 在騰訊雲的穩定性實踐
- 迎接2023 | 北極星開源一週年,感恩禮傾情相送
- Apache Pulsar 技術系列 – 基於不同部署策略和配置策略的容災保障
- 輕量級SaaS化應用數據鏈路構建方案的技術探索及落地實踐
- 微服務架構下路由、多活、灰度、限流的探索與挑戰
- PolarisMesh北極星 V1.11.3 版本發佈
- 千億級、大規模:騰訊超大 Apache Pulsar 集羣性能調優實踐
- Apache Pulsar 系列 —— 深入理解 Bookie GC 回收機制
- 騰訊雲微服務引擎 TSE 產品動態
- 千億級、大規模:騰訊超大 Apache Pulsar 集羣性能調優實踐
- TSF微服務治理實戰系列(三)——服務限流
- 如何解決 Spring Cloud 下測試環境路由問題
- TSF微服務治理實戰系列(二)——服務路由