導語：微服務網關作為後臺架構的入口，提供路由轉發、API 管理、訪問過濾器等作用，是微服務架構中的重要組件。開源社區中存在多種方式實現微服務網關的功能，但同時也存在不靈活、運維難的問題。本文從實際業務場景出發，通過實際操作為大家演示騰訊雲微服務平臺TSF(Tencent Service Framework)是如何解決上述問題的。
前言
微服務網關通過服務路由、API管理、負載均衡、訪問限制等功能，在一定程度上可以實現服務治理，幫助我們管理各個服務之間的調用及關聯關係。我們來看這樣一個場景：當有外部請求時，我們希望依據某些參數值來決定路由可轉發到服務的某個版本，或依據參數值對請求進行限流、鑑權等操作。如下圖所示，外網請求通過網關訪問後端微服務，當請求參數 region = guangzhou時，我們希望可以路由轉發到微服務的版本1中；當region = shanghai時，路由可以轉發到微服務的版本2中。
這個場景在實際業務中非常常見，那我們先來看下使用開源方案實現基於業務參數的服務治理。
開源社區中服務路由能力初探
在開源社區中，根據不同語言和微服務的技術選型，有以下幾種方式實現服務路由能力。
傳統路由配置
當我們不依賴服務發現機制的時候，我們通常需要通過具體的配置文件來指定路由的表達式與服務實例的映射關係。當網關調用某個微服務時，若微服務上有多個節點需要進行負載均衡，則需要如下配置：
<code>zuul.routes.user-service.path=/user/**
zuul.routes.user-service.serviceId=user
ribbon.eureka.enabled=false
user-service.ribbon.listOfServers=http://localhost:8080/,http://localhost:8081//<code>
以此來實現/user/**的請求轉發到兩個實例上去。
很容易發現這種配置方式有以下幾個問題：
- 對於實現前文中的架構圖的路由方式，至少需要將B服務拆分成為兩個不同名稱的微服務，在網關、A服務上共配置三次路由規則才能實現三個微服務之間基於請求參數的服務路由能力。配置非常複雜。
- 由於沒有註冊中心，我們沒法對節點的狀態進行檢測和剔除，當系統中出現壞死節點，必須改變路由配置才能讓業務恢復運行。運維困難。
- 配置後需要重啟網關實例配置才能生效，無法熱生效。
Spring Cloud實現
當我們依賴原生Spring Cloud的的註冊中心：Consul或Euraka 以及 原生的微服務網關組件 Zuul或者Spring Cloud Gateway來實現服務的自動註冊與發現，在網關層面，不需要將節點ip配置在轉發路徑上，註冊中心將為我們提供服務與節點的對應關係。
由於只有在網關處可以實現依據不同請求參數轉發請求到不同微服務，上圖中的架構圖需要調整為：其中A1 A2，B1 B2 都在不同的實例上。
在實現上，我們需要這樣配置：
在網關上配置不同請求參數轉發到不同的微服務A中。儘管B1和B2 服務僅僅有一些版本上的差異，接口相同，但是由於無法直接實現A服務依據不同參數轉發到B服務的不同實例上，需要將A服務也拆成兩個服務來保證請求的一一對應。
zuul.routes.A1=/user1/**
zuul.routes.A2=/user2/**
這樣配置依然存在以下問題：
- 儘管不需要配置實際的節點對應關係，但是由於無法實現微服務之間的不同請求參數轉發到不同節點，需要拆分多個微服務，非常複雜。
- 而且由於路由配置需要寫在properties中，如果需要調整路由則需要重啟網關。無法靈活調整。
TSF微服務網關路由能力
從上述業務場景中，開源Spring Cloud架構在實現上相對麻煩，很難滿足實際業務中複雜多變的使用場景。在騰訊微服務平臺TSF中，我們提供了以上場景的解決方案，方案的優勢為：
- 頁面化配置，無需修改代碼，上手方便。管理方便
- 隨時控制規則生效狀態，立即生效，無需重啟。
- 可以靈活實現基於業務參數的路由、限流、鑑權策略，並且可以依據業務參數進行單條請求的過濾，方便運維。
- 支持可視化運維，可直接查看路由、限流規則的生效情況，也可以查看監控平臺。
使用TSF實現基於業務業務參數的最佳實踐
開始進行本實踐之前，你需要先了解 下TSF 中的以下功能：
- 微服務網關的部署：微服務網關是微服務的請求入口，它本身也是一個微服務。用戶可以通過微服務網關託管不同微服務的API。詳細微服務網關的部署方式請參考微服務網關部署。
- 服務路由：用戶可以配置流量分配權重，設置某些權重的流量被分配到某個版本號中，為灰度發佈等上線模式提供了無需終止服務的底層能力支持。
下面就開始我們的基於業務參數的服務治理實踐指引。
下面就開始我們的基於業務參數的服務治理實踐指引。
準備工作
- 準備兩個微服務 consumer -demo；provider - demo。其中provider - demo存在兩個版本的包provider-demo-guangzhou.jar，provider-demo-shanghai.jar。兩個版本在訪問請求攜帶region參數並訪問 /test-region 接口時，會分別返回 shanghai和guangzhou。請求provider - demo時，可以攜帶兩個 Header 參數，region 和usertype。 consumer - demo部署在一個部署組上，provider - demo部署在兩個部署組上，每個部署組部署一個版本的jar包。
- 部署一個微服務網關，使用官網 demo ，部署後服務名為 msgw - demo，部署組名稱為test，默認端口為8080 （請注意給對應機器開放8080端口。）在本demo中，將直接通過網關訪問微服務provider。
- 新建微服務網關分組，並將微服務網關分組綁定在創建好的網關應用部署組上。
- 將微服務API導入到分組中，並將分組進行發佈。
配置微服務網關插件
在這一步中，我們在網關配置插件，將請求參數轉化為 TSF 中的標籤信息。
- 在 TSF 控制檯 選擇組建中心 - 微服務網關 - 插件管理，點擊新建插件
- 創建插件類型為 tag 類型插件，將請求參數中 Header 參數中的 region、usertype 設置為標籤
- 在插件列表頁面將創建好的插件與準備工作中創建的分組進行綁定
配置服務治理規則
在這一步中，我們配置依據上一步已經轉化的標籤，配置服務治理規則。當前 TSF 標籤可以與服務路由、服務鑑權、服務限流、調用鏈進行聯動。本文中為您介紹路由、鑑權、以及調用鏈聯動功能。
服務路由
- 登陸 TSF 控制檯，點擊服務治理，找到創建好的 provider - demo 微服務，點擊詳情至服務路由頁面。請注意，路由規則始終是在被調用方進行配置的。
- 新建服務路由規則。 創建兩條規則，當自定義標籤region值為guangzhou時，100%的流量指向部署了provider-demo-guangzhou.jar的部署組，當自定義標籤region值為shanghai時，100%的流量指向部署了provider-demo-shanghai.jar的部署組。規則配置可參考下圖：
- 生效規則，效果驗證：
公網發送請求 ：129.XX.XX.XX:8080/test-region…
攜帶Header參數 region = shanghai
驗證後，發現請求的確路由到了返回值為 shanghai 的部署組中
同理，當請求 Header 參數 = guangzhou時，請求也路由到了返回值為 guangzhou 的部署組中。
服務鑑權
- 登陸 TSF 控制檯，點擊服務治理，找到創建好的 provider - demo 微服務，點擊詳情至服務鑑權頁面。
- 配置服務鑑權規則，我們希望實現的是，當請求參數 Header 中攜帶了參數usertype = user時，請求不通過。配置方式如下，選擇自定義標籤，usertype = user 生效。
- 結果驗證:同理發送請求，攜帶 Header 參數usertype = user，region = shanghai。發現返回請求失敗。
調用鏈查詢
在 TSF 中，我們提供了基於請求標籤過濾調用鏈的能力，您可以依據業務數據過濾對應請求的調用鏈。最為常見的場景是查詢某個用戶id的請求調用成功失敗情況以及層級耗時。
使用方法
- 訪問 TSF 控制檯，點擊運維中心 - 調用鏈查詢，選擇對應的命名空間和微服務
- 點擊 “展開高級查詢條件”
- 輸入查詢標籤，此處我們輸入 userid：1000001，過濾userid 為1000001的請求數據
- 如圖所示，下面查詢的數據即為攜帶對應標籤的請求trace列表。
作者：騰訊雲中間件
原文鏈接：https://juejin.im/post/5e84870a51882573793e6ab6
閱讀更多 追逐仰望星空 的文章
