TSF微服務治理實戰系列（二）——服務路由

在服務實例數量和規模較大的業務場景下，服務路由是系統比較常見的訴求，比如針對業務屬性的全鏈路灰度、測試環境多分支路由、多Region多AZ時的就近路由等。TSF基於標籤化能力完成流量染色和標籤自動傳遞，僅通過控制枱配置即可實現服務路由、全鏈路灰度及就近路由功能，快速滿足客户的業務分流訴求。服務路由從行為上講，是將流量進行染色區分，並通過路由規則將流量進行分流，本節將對TSF整體服務路由相關能力進行詳細介紹。

治理路由

功能説明

容錯保護

在使用治理路由時，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分支使用的資源即可，不再需要進行版本替換和上下文更新，極大節省運維成本、提高測試效率。

• 新建Service B、Service C的hotfix版本部署組，並完成應用發佈。

• 在Servcie B及Service C的服務治理->服務路由中新建路由規則，保存並開啟。

當在控制枱開啟治理路由規則時，規則會對應用實時生效。通過上述步驟即可快速實現測試環境多分支的治理路由配置。另外，假設Service C關聯了更多的版本/部署組（如4個），則只需針對Service C進行路由規則的添加即可，並不影響Service B的路由配置。

全鏈路灰度

功能説明

隨着系統架構向微服務轉變，應用的發佈頻率和次數都明顯增高。尤其當微服務的規模越來越大，如何能夠在保證低運維成本、故障爆炸半徑可控的情況下，完成全鏈路大規模的發佈動作，成為研發及運維部門面臨的難題。

全鏈路灰度是軟件逐步上線常用的發佈方式，是指將具有一定特徵或者比例的流量，逐步分配到指定版本的過程，通過生產流量實測發現新版本可能存在的潛在問題，同時將故障損失控制在灰度範圍內。

相比全量上線，灰度發佈是更加謹慎的發佈形式。當線上調用鏈路較為複雜時，全鏈路灰度發佈可以將生產環境隔離出一個邏輯獨立的運行環境。同時，全鏈路灰度的泳道可以反覆使用，即使進行變動也比較靈活，使得全鏈路灰度的運維成本也縮小很多。

使用全鏈路灰度發佈之前，需要先配置泳道。一條泳道相當於一個灰度環境，環境中包含應用中需要進行灰度測試的部署組。

泳道：泳道是一組業務關聯的部署組的集合，是灰度流量的目的地。泳道中的部署組屬於不同的應用，可以認為用户通過劃分泳道而劃分出了灰度環境。

灰度規則：用户新建灰度規則以設定灰度流量應滿足的條件。當灰度規則判斷請求滿足條件後，會通過灰度規則將流量路由到某一個泳道中。

泳道入口 ： 在全鏈路灰度發佈模塊中發佈灰度規則時，會在泳道的入口部署組上對請求進行灰度規則校驗，以此來判斷請求是否應該進入某一個泳道中。泳道入口可以是一個微服務網關，也可以是一個微服務。

同一個泳道中支持多個入口，在請求經過每一個入口部署組時，都會判斷請求是否應該進入泳道中。

TSF全鏈路灰度發佈的操作流程如下圖，詳細操作步驟可瀏覽TSF官網進行查閲。https://cloud.tencent.com/document/product/649/43463

全鏈路灰度流量流向規則與説明

• 當泳道上已經綁定了全鏈路灰度發佈的規則，則不能刪除泳道。

• 當 請求流量沒有命中任何灰度規則，流量將走到沒有被添加到泳道的部署組中。

• 當某一個微服務下的部署組沒有被加入任何泳道中，請求將在該微服務下所有部署組的所有實例中輪詢。經過該微服務後，請求將繼續按照規則流入對應泳道。

• 一個部署組可以屬於多個泳道。

• 在泳道中，服務路由規則不生效。

• 泳道是一個隔離環境。 當泳道上所有規則關閉後，流量不會進入泳道中。如希望恢復建立泳道前的流量分配方式，請將泳道刪除。

全鏈路灰度中消息主題染色

kafka作為主流的消息隊列產品之一，經常用做業務邏輯間的解耦及大數據場景。那麼在全鏈路灰度發佈時，服務間調用如果使用了kafka做異步解耦，在消息未被染色時就會出現Consumer錯誤的消費了其它泳道消息的現象，這是業務不能接受的。

TSF通過將泳道標記在線程中向下傳遞的方式實現消息染色，即染色流量能在流經kafka後被對應泳道中的部署組消費，而未染色消息被不在任何泳道中的部署組消費，並且泳道標（即LaneId）能在消息流經kafka後繼續傳遞給下游服務。詳情請參見官網最佳實踐：https://cloud.tencent.com/document/product/649/75454

適用場景

全鏈路灰度發佈是大規模微服務架構場景下幾乎必備的發佈方式，它可以滿足指定小流量驗證、逐級切流控制故障範圍、多個關聯服務一次性共同發佈、一次配置反覆使用等要求，有效減少了發佈成本及上線變更帶來的風險。

基於地域和用户的灰度測試場景

互聯網產品經常會邀請公測用户進行體驗，當產品需要上線新功能時，希望使用灰度發佈的手段在小範圍內進行新版本發佈測試。在測試一段時間後，逐步的增加新版本的流量比例，同時減少原有版本的流量比例。上述這種灰度發佈的模式，不同於以往新舊版本發佈的一次性切換，讓整個發佈過程通過灰度發佈的方式進行過渡。

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）的隔離，保證每個單元的獨立。

適用場景

單元化適用場景主要集中在大規模或超大規模的分佈式系統中，同時從企業成本和管理角度講，整個單元化改造的過程是漫長的、成本是巨大的，實際情況可能是企業內部系統架構在擴展性、可用性、性能存在多方面痛點，不得不通過單元化改造來解決現有問題。

銀行業務單元化改造場景

單元化改造中單元化規則的設計是重中之重，且銀行業務一般情況不涉及到地域等其它屬性，所以主要還是從用户的業務屬性出發進行設計。

首先以用户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。

更多詳細配置請參見：https://cloud.tencent.com/document/product/649/33797

結語

路由主要是解決流量如何分類，以及從哪裏來、到哪裏去的問題，本節通過對治理路由、全鏈路灰度、單元化、就近路由的功能及實踐場景的描述，展示了TSF在流量路由方面的核心能力，基本覆蓋了主要的流量路由場景，希望能給讀者朋友提供一點幫助。

引用

往期

推薦

掃描下方二維碼關注本公眾號，

瞭解更多微服務、消息隊列的相關信息！

解鎖超多鵝廠周邊！