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官網進行查閱。http://cloud.tencent.com/document/product/649/43463

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

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

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

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

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

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

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

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

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

TSF通過將泳道標記線上程中向下傳遞的方式實現訊息染色，即染色流量能在流經kafka後被對應泳道中的部署組消費，而未染色訊息被不在任何泳道中的部署組消費，並且泳道標（即LaneId）能在訊息流經kafka後繼續傳遞給下游服務。詳情請參見官網最佳實踐：http://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。

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

結語

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

引用

往期

推薦

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

瞭解更多微服務、訊息佇列的相關資訊！

解鎖超多鵝廠周邊！