TSF微服務治理實戰系列(二)——服務路由

語言: CN / TW / HK

導語

在服務例項數量和規模較大的業務場景下,服務路由是系統比較常見的訴求,比如針對業務屬性的全鏈路灰度、測試環境多分支路由、多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的資訊!

點個 在看 你最好看