作者｜曾宇星（宇曾）
審核&校對：曾宇星（宇曾）
編輯&排版：雯燕

背景

微服務軟件架構下，業務新功能上線前搭建完整的一套測試系統進行驗證是相當費人費時的事，隨著所拆分出微服務數量的不斷增大其難度也愈大。這一整套測試系統所需付出的機器成本往往也不低，為了保證應用新版本上線前的功能正確性驗證效率，這套系統還必須一直單獨維護好。當業務變得龐大且復雜時，往往還得準備多套，這是整個行業共同面臨且難解的成本和效率挑戰。如果能在同一套生產系統中完成新版本上線前的功能驗證的話，所節約的人力和財力是相當可觀的。

除了開發階段的功能驗證，生產環境中引入灰度發布才能更好地控制新版本軟件上線的風險和爆炸半徑。灰度發布是將具有一定特征或者比例的生產流量分配到需要被驗證的服務版本中，以觀察新版本上線后的運行狀態是否符合預期。

阿里云 ASM Pro（相關鏈接請見文末）基于 Service Mesh 所構建的全鏈路灰度方案，能很好幫助解決以上兩個場景的問題。

ASM Pro 產品功能架構圖：

核心能力使用的就是上圖擴展的流量打標和按標路由以及流量 Fallback 的能力，下面詳細介紹說明。

場景說明

全鏈路灰度發布的常見場景如下：

以 Bookinfo 為例，入口流量會帶上期望的 tag 分組，sidecar 通過獲取請求上下文（Header 或 Context) 中的期望 tag，將流量路由分發到對應 tag 分組，若對應 tag 分組不存在，默認會 fallback 路由到 base 分組，具體 fallback 策略可配置。接下來詳細描述具體的實現細節。

入口流量的 tag 標簽，一般是在網關層面基于類似 tag 插件的方式，將請求流量進行打標。 比如將 userid 處于一定范圍的打上代表灰度的 tag，考慮到實際環境網關的選擇和實現的多樣性，網關這塊實現不在本文討論的范圍內。

下面我們著重討論基于 ASM Pro 如何做到全鏈路流量打標和實現全鏈路灰度。

實現原理

Inbound 是指請求發到 App 的入口流量，Outbond 是指 App 向外發起請求的出口流量。

上圖是一個業務應用在開啟 mesh 后典型流量路徑：業務 App 接收到一個外部請求 p1，接著調用背后所依賴的另一個服務的接口。此時，請求的流量路徑是 p1->p2->p3->p4，其中 p2 是 Sidecar 對 p1 的轉發，p4 是 Sidecar 對 p3 的轉發。為了實現全鏈路灰度，p3 和 p4 都需要獲取到 p1 進來的流量標簽，才能將請求路由到標簽所對應的后端服務實例，且 p3 和 p4 也要帶上同樣的標簽。關鍵在于，如何讓標簽的傳遞對于應用完全無感，從而實現全鏈路的標簽透傳，這是全鏈路灰度的關鍵技術。ASM Pro 的實現是基于分布式鏈路追蹤技術（比如，OpenTracing、OpenTelemetry 等）中的 traceId 來實現這一功能。

在分布式鏈路追蹤技術中，traceId 被用于唯一地標識一個完整的調用鏈，鏈路上的每一個應用所發出的扇出（fanout）調用，都會通過分布式鏈路追蹤的 SDK 將源頭的 traceId 給帶上。ASM Pro 全鏈路灰度解決方案的實現正是建立在這一分布式應用架構所廣泛采納的實踐之上的。

上圖中，Sidecar 本來所看到的 inbound 和 outbound 流量是完全獨立的，無法感知兩者的對應關系，也不清楚一個 inbound 請求是否導致了多個 outbound 請求的發生。換句話說，圖中 p1 和 p3 兩個請求之間是否有對應關系 Sidecar 并不知情。

在 ASM Pro 全鏈路灰度解決方案中，通過 traceId 將 p1 和 p3 兩個請求做關聯，具體說來依賴了 Sidecar 中的 x-request-id 這個 trace header。Sidecar 內部維護了一張映射表，其中記錄了 traceId 和標簽的對應關系。當 Sidecar 收到 p1 請求時，將請求中的 traceId 和標簽存儲到這張表中。當收到 p3 請求時，從映射表中查詢獲得 traceId 所對應的標簽并將這一標簽加入到 p4 請求中，從而實現全鏈路的打標和按標路由。下圖大致示例了這一實現原理。

換句話說，ASM Pro 的全鏈路灰度功能需要應用使用分布式鏈路追蹤技術。如果想運用這一技術的應用沒有使用分布式鏈路追蹤技術的話不可避免地涉及到一定的改造工作。對于 Java 應用來說，仍可以考慮采用 Java Agent 以 AOP 的方式讓業務無需改造地實現 traceId 在 inbound 和 outbound 之間透傳。

實現流量打標

ASM Pro 中引入了全新的 TrafficLabel CRD 用于定義 Sidecar 所需透傳的流量標簽從哪里獲取。下面所例舉的 YAML 文件中，定義了流量標簽來源和需要將標簽存儲 OpenTracing 中（具體是 x-trace 頭）。其中流量標的名為 trafficLabel，取值依次從 $getContext(x?request?id)到最后從本地環境的$(localLabel)中獲取。

apiVersion: istio.alibabacloud.com/v1beta1 kind: TrafficLabel metadata:name: default spec:rules:- labels:- name: trafficLabelvalueFrom:- $getContext(x-request-id) //若使用aliyun arms,對應為x-b3-traceid- $(localLabel)attachTo:- opentracing# 表示生效的協議，空為都不生效，*為都生效protocols: "*"

CR 定義包含兩塊，即標簽的獲取和存儲。

• 獲取邏輯：先根據協議上下文或者頭（Header 部分）中的定義的字段獲取流量標簽，如果沒有，會根據 traceId 通過 Sidecar 本地記錄的 map 獲取, 該 map 表中保存了 traceId 對應流量標識的映射。若 map 表中找到對應映射，會將該流量打上對應的流量標，若獲取不到，會將流量標取值為本地部署對應環境的 localLabel。localLabel 對應本地部署的關聯 label，label 名為 ASM_TRAFFIC_TAG。

本地部署對應環境的標簽名為"ASM_TRAFFIC_TAG"，實際部署可以結合 CI/CD 系統來關聯。

• 存儲邏輯：attachTo 指定存儲在協議上下文的對應字段，比如 HTTP 對應 Header 字段，Dubbo 對應 rpc context 部分，具體存儲到哪一個字段中可配置。

有了TrafficLabel 的定義，我們知道如何將流量打標和傳遞標簽，但光有這個還不足以做到全鏈路灰度，我們還需要一個可以基于 trafficLabel 流量標識來做路由的功能，也就是“按標路由”，以及路由 fallback 等邏輯，以便當路由的目的地不存在時，可以實現降級的功能。

按流量標簽路由

這一功能的實現擴展了 Istio 的 VirtualService 和 DestinationRule。

在 DestinationRule 中定義 Subset

自定義分組 subset 對應的是 trafficLabel 的 value

apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata:name: myapp spec:host: myapp/*subsets:- name: myproject # 項目環境labels:env: abc- name: isolation # 隔離環境labels:env: xxx # 機器分組- name: testing-trunk # 主干環境labels:env: yyy- name: testing # 日常環境labels:env: zzz --- apiVersion: networking.istio.io/v1alpha3 kind: ServiceEntry metadata:name: myapp spec:hosts: - myapp/*ports:- number: 12200name: httpprotocol: HTTPendpoints:- address: 0.0.0.0labels:env: abc- address: 1.1.1.1labels:env: xxx- address: 2.2.2.2labels:env: zzz- address: 3.3.3.3labels:env: yyy

Subset 支持兩種指定形式：

• labels 用于匹配應用中帶特定標記的節點（endpoint）；
• 通過 ServiceEntry 用于指定屬于特定 subset 的 IP 地址，注意這種方式與labels指定邏輯不同，它們可以不是從注冊中心（K8s 或者其他）拿到的地址，直接通過配置的方式指定。適用于 Mock 環境，這個環境下的節點并沒有向服務注冊中心注冊。

在 VirtualService 中基于 subset

1）全局默認配置

• route 部分可以按順序指定多個 destination，多個 destination 之間按照 weight 值的比例來分配流量。
• 每個 destination 下可以指定 fallback 策略，case 標識在什么情況下執行 fallback，取值：noinstances（無服務資源）、noavailabled（有服務資源但是服務不可用），target 指定 fallback 的目標環境。如果不指定 fallback，則強制在該 destination 的環境下執行。
• 按標路由邏輯，我們通過改造 VirtualService，讓 subset 支持占位符 $trafficLabel, 該占位符 $trafficLabel 表示從請求流量標中獲取目標環境， 對應 TrafficLabel CR 中的定義。

全局默認模式對應泳道，也就是單個環境內封閉，同時指定了環境級別的 fallback 策略。自定義分組 subset 對應的是 trafficLabel 的 value

配置樣例如下：

apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata:name: default-route spec:hosts: # 對所有應用生效- */*http:- name: default-routeroute:- destination:subset: $trafficLabelweight: 100fallback:case: noinstancestarget: testing-trunk- destination:host: */*subset: testing-trunk # 主干環境weight: 0fallback:case: noavailabledtarget: testing- destination:subset: testing # 日常環境weight: 0fallback:case: noavailabledtarget: mock- destination:host: */*subset: mock # Mock中心weight: 0

2）個人開發環境定制

• 先打到日常環境，當日常環境沒有服務資源時，再打到主干環境。

apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata:name: projectx-route spec:hosts: # 只對myapp生效- myapp/*http:- name: dev-x-routematch:trafficLabel:- exact: dev-x # dev環境: xroute:- destination:host: myapp/*subset: testing # 日常環境weight: 100fallback:case: noinstancestarget: testing-trunk- destination:host: myapp/*subset: testing-trunk # 主干環境weight: 0

3） 支持權重配置

將打了主干環境標并且本機環境是 dev-x 的流量，80% 打到主干環境，20% 打到日常環境。當主干環境沒有可用的服務資源時，流量打到日常。

sourceLabels 為本地 workload 對應的 label

apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata:name: dev-x-route spec:hosts: # 對哪些應用生效（不支持多應用配置）- myapp/*http:- name: dev-x-routematch:trafficLabel:- exact: testing-trunk # 主干環境標sourceLabels:- exact: dev-x # 流量來自某個項目環境route:- destination:host: myapp/*subset: testing-trunk # 80%流量打向主干環境weight: 80fallback:case: noavailabledtarget: testing- destination：host: myapp/*subset: testing # 20%流量打向日常環境weight: 20

按（環境）標路由

該方案依賴業務部署應用時帶上相關標識（例子中對應 label 為 ASM_TRAFFIC_TAG: xxx），常見為環境標識，標識可以理解是服務部署的相關元信息，這個依賴上游部署系統 CI/CD 系統的串聯，大概示意圖如下：

• K8s 場景，通過業務部署時自動帶上對應環境/分組 label 標識即可，也就是采用K8s 本身作為元數據管理中心。
• 非 K8s 場景，可以通過微服務已集成的服務注冊中心或者元數據配置管理服務（metadata server）來集成實現。

注：ASM Pro 自研開發了ServiceDiretory 組件（可以參看 ASM Pro 產品功能架構圖），實現了多注冊中心對接以及部署元信息的動態獲取；

應用場景延伸

下面是典型的一個基于流量打標和按標路由實現的多套開發環境治理功能；每個開發者對應的 Dev X 環境只需部署有版本更新的服務即可；如果需要和其他開發者聯調，可以通過配置 fallback 將服務請求 fallback 流轉到對應開發環境即可。如下圖的 Dev Y 環境的B -> Dev X 環境的 C。

同理，將 Dev X 環境等同于線上灰度版本環境也是可以的，對應可以解決線上環境的全鏈路灰度發布問題。

總結

本文介紹的基于“流量打標”和“按標路由” 能力是一個通用方案，基于此可以較好地解決測試環境治理、線上全鏈路灰度發布等相關問題，基于服務網格技術做到與開發語言無關。同時，該方案適應于不同的7層協議，當前已支持 HTTP/gRpc 和 Dubbo 協議。

對應全鏈路灰度，其他廠商也有一些方案，對比其他方案 ASM Pro 的解決方案的優點是：

• 支持多語言、多協議。
• 統一配置模板 TrafficLabel， 配置簡單且靈活，支持多級別的配置（全局、namespace 、pod 級別）。
• 支持路由 fallback 實現降級。

基于“流量打標” 和 “按標路由”能力還可以用于其他相關場景：

• 大促前的性能壓測。在線上壓測的場景中，為了讓壓測數據和正式的線上數據實現隔離，常用的方法是對于消息隊列，緩存，數據庫使用影子的方式。這就需要流量打標的技術，通過 tag 區分請求是測試流量還是生產流量。當然，這需要 Sidecar 對中間件比如 Redis、RocketMQ 等進行支持。
• 單元化路由。常見的單元化路由場景，可能是需要根據請求流量中的某些元信息比如 uid，然后通過配置得出對應所屬的單元。在這個場景中，我們可以通過擴展 TrafficLabel 定義獲取“單元標”的函數來給流量打上“單元標”，然后基于“單元標”將流量路由到對應的服務單元。

相關鏈接：

1）阿里云 ASM Pro：
https://servicemesh.console.aliyun.com/

總結

以上是生活随笔為你收集整理的基于 Istio 的全链路灰度方案探索和实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。