貨拉拉應用多分組架構設計方案分享

　　 一、背景

　　貨拉拉為微服務架構提供了多種服務發現和服務路由的能力，截止目前（2023年初），服務發現提供了透過 Consul 和域名降級兩種發現方式，服務路由已提供了灰度路由、多泳道路由等多種路由能力。

　　然而隨著業務發展和基礎設施建設，對服務發現與路由能力有了更靈活的需求，目前已經陸續收集到如下訴求：

　　• 服務分多個分組釋出

　　￮ 不同分組執行不同版本的業務程式碼，從而實現業務灰度或業務 AB 版本

　　￮ 不同分組有著不同的穩定性要求，例如部署著不同的例項數等

　　• 服務呼叫方可以根據不同的場景需要，選擇呼叫不同的服務端分組

　　• 不同的業務場景可以透過閘道器和 SOA 路由配置或自定義靈活的路由策略

　　• 等等

　　經過對貨拉拉現狀以及上述需求的詳細瞭解，並結合業界對微服務路由的優秀實踐，我們決定引入“應用多分組架構”來滿足業務的需求

　 　二、基本原理

　　2.1

　　架構基本原理

　　應用多分組架構的基本原理是如何解決下面三個問題

　　服務如何多分組部署？

　　怎麼進行多分組的服務發現與路由？

　　路由策略如何滿足不同的業務場景？

　　2.1.1 應用多分組部署

　　應用多分組架構基礎是需要支援同一 appid 的分分組部署，並且不同分組可以配置不同的釋出配置，同時執行在不同分組的程式也可以感知到自己所屬的分組　　

　　2.1.2多分組服務發現與路由

　　SOA SDK 透過感知服務所屬分組配置進行 Consul 打標，從而提供統一的應用多分組發現和路由機制　　

　　2.1.3 路由策略

　　多分組架構將透過兩種方式提供靈活的路由策略，滿足不同業務場景：

　　1. 多分組架構內建路由策略：將提供靜態路由、協議頭路由、開關、黑白名單、降級等路由策略，滿足大部分情況下的多分組訴求

　　2. 提供路由策略擴充套件機制，滿足業務自定義策略，例如

　　a. SOA 的 SPI 擴充套件機制

　　b. LAPIGateway 的外掛機制　　

　　2.1.4 其他問題

　　除了上述三個基本問題，多分組架構還應該考慮如下問題：

　　• 多分組架構涉及的環境和後設資料統一規範

　　• 多分組架構的可觀測性設計

　　• 配置中心支援不同分組差異化配置

　　• 開放相關能力給業務方組合自定義場景問題等等

　　2.2

　　可以解決的問題

　　應用多分組架構可以解決的問題如下：

　　• 同一個 appid 不拆分的情況下，在不同分組執行不同版本的業務程式碼

　　• 相同版本的程式碼在不同分組部署擁有不同的配置，例如：配置中心、例項數量、 HPA 規則等等

　　• 服務呼叫方可以根據不同的場景需要，選擇呼叫不同的服務端分組，也可以透過閘道器 + SOA 路由配置靈活的多分組路由策略

　　 三、架構設計

　　應用多分組架構涉及的範圍集中在微服務相關元件，不涉及流量接入層和資料層

　　• ① 鏈路透過閘道器路由策略控制分組匹配

　　• ② 鏈路透過 SDK 路由策略控制分組匹配

　　分組是應用下一級的概念，分組屬於應用，下圖虛線圈定部分僅為應用下同名的邏輯概念　　

　　3.2

　　多分組路由

　　只有滿足了多分組路由規則的請求才會路由到對應的分組服務，多分組路由核心約定包括如下兩個要素

　　1. 透過上述服務序號產生器制已經為服務例項進行打標 Consul tag(hll.group)，用於服務發現

　　2. 分組路由只提供一級路由（A -> B），不涉及協議頭和鏈路透傳能力，同時分組路由提供靜態路由和擴充套件點

　　a. SDK 提供靜態服務引用引數 group（非必填）

　　b. 多分組路由　　

　　3.1

　　多分組服務註冊

　　SOA 服務在註冊時會額外寫入了服務例項的分組標識，將透過新增 Consul tag(hll.group) 承載，空值不寫入 tag，consul tag 現狀如下圖所　　

　　SOA 獲取分組後設資料依賴於對服務例項分組的感知能力，例如：透過環境變數

　　hll_group

　　分組路由流程圖如下圖

　　下圖邏輯均在 SOA 客戶端執行　　

　　同時為了方便了解多分組路由與其他路由關係以及後續的擴充套件機制，可以瞭解多分組路由在 SOA SDK 內部位置

　　3.3

　　分組路由擴充套件機制

　　如上多分組架構整體方案所述，SOA 框架需要提供路由策略擴充套件機制，滿足業務自定義策略

　　• 分組路由擴充套件獲取的分組優先順序高於內建機制

　　• 分組路由擴充套件機制設計原則

　　￮ 【輸出】對預設路由策略干預儘可能收斂

　　▪ 只能改變本次請求的分組標識選擇

　　▪ 存在多個 SPI 時，高優先順序 SPI 決策成功阻塞後續 SPI 執行

　　￮ 【輸入】儘可能多的提供路由決策所需要的資料，比如：當前服務資訊、協議頭、註冊資訊等等

　　▪ List<Invoker<T>> invokers: 下游節點資訊

　　▪ Invocation invocation: 呼叫上下文資訊

　　▪ MetaContextUtil、RpcContext 等工具類

　　• 擴充套件方式按 SOA 慣例，使用 SPI 機制

　　Java// SPI 虛擬碼@SPI(internal = false)public interface GroupRouterExt { Optional<PinnedGroup> getGroup(List<Invoker<T>> invokers, Invocation i);}// 內部類public class PinnedGroup { // 分組標識 private String group; // 無匹配分組時是否允許跨分組呼叫，預設 false private boolean cross;}

　 　四、應用場景

　　SOA服務多分組在開發中有許多應用場景，以下是一些常見的應用場景：

　　4.1

　　功能模組劃分

　　將服務例項按照不同的功能模組進行劃分，每個功能模組對應一個服務分組。這樣可以將不同的功能模組進行解耦，提高系統的可維護性和可測試性。舉例：XXX 服務提供 A、B兩個功能介面，針對不同的上游提供不同的分組　　

　　4.2

　　業務領域劃分

　　根據業務的不同領域將相關的服務例項劃分到不同的服務分組中。這樣可以使得每個服務分組的資源更有效利用，提高系統的吞吐量。舉例：假如user 和 driver 的token provider服務的程式碼是同一套並且只申請一個 appid，那麼我們可以針對上游的使用者和司機的token consumer服務提供兩個分組服務　　

　　4.3

　　服務SLA

　　將相同服務 SLA 的服務例項劃分到同一個服務分組中，方便進行隔離和最佳化。舉例：XXX 服務給 QPS 較高和 RT 較小的 APP 端介面服務、QPS 較小和 RT較高的運營端介面服務提供不同的分組　　

　　4.4

　　技術棧劃分

　　根據不同的技術棧將相關的服務例項劃分到不同的服務分組中。例如，將給前端呼叫的服務服務例項、給後端內部呼叫服務例項和給資料服務呼叫的服務例項分別劃分到不同的服務分組中，每個分組使用不同的例項數量，提高資源的利用率

　　4.5

　　安全和許可權管理

　　將具有相似安全需求或許可權管理需求的服務例項劃分到同一個服務分組中，方便進行統一的安全策略和許可權控制

　　ps：程式碼相似度較高或者程式碼放在同一個APPID 中更好維護，那麼我們可以在不拆分服務（APPID）的情況下，可以使用 SOA多分組方式給不同的上游提供服務