★ ServiceMesh系列
1 什麼是流量染色
在複雜的生產場景中，經常會有同一個服務中，存在多個版本長期共存的需求。為了讓不同的使用者在不一樣的版本中使用，就需要對使用者的請求進行取樣和染色，打上不同的標識。
這樣的目的有幾個：
- 支撐分級釋出，避免全量釋出時可能遇到的大規模風險，如系統崩潰、使用者流失。
- 支援染色實驗，讓部分人優先體驗新版本或者實驗功能
- QA的線上問題分析、驗證、除錯，甚至壓測都可以放在染色部署區域去做，因為是強隔離模式，可以避免對線上其他使用者的影響
使用Service Mesh的流量染色能力，可以在單個服務中根據特徵值進行多元版本流量分發。特別是鏈路繁瑣的巨型網格中，能夠管理長達10個以上的鏈路分流排程，這個能力顯得非常重要。常見的 Canary Release（金絲雀）、ABTesting、Diversified Version（多版本分流），都是基於此類演算法實現。這邊介紹在無侵入業務的情況下，Mesh如何實現流量染色。
1. Canary Release
2. Diversified Version
3. Diversified Version
2 Mesh使用標籤特性進行染色
Mesh如果想要實現流量染色，需要具備以下幾個條件：
- 請求的流量中，需要附帶某些特徵，如流量的請求的Header、Cookies、queryParams等，它們帶有某些資訊。
- 部署多版本服務
- 部署在kubernetes上的服務（svc）的例項（pod）需要接入Mesh，並打上版本標籤
- 或者建立不同的服務（svc），後面把流量引入到這個新的服務上去
- 在Mesh平臺上對應的服務中配上策略：當請求的流量帶有某些特徵（如header中帶有UserID=12345678）時，流量路由到對應標籤（如 version = v1.7 ）的服務例項上。
- 不符合條件的路由則預設走到預設版本中（如 version = default）。
所以，Mesh的染色本質上是透過在流量中攜帶一些特徵（如流量的請求的Header、Cookies、queryParams等），而Mesh會根據這些請求的特徵進行路由匹配，轉發到對應的帶有某些特徵的服務例項上。
未匹配成功的流量則走到預設版本中，從而實現多個版本和跟預設版本的業務隔離的目標。
2.1 Mesh 染色流轉原理
2.1.1 Istio支援的策略模型
即Istio支援的流量特徵包括uri、scheme、method、headers、queryParams等條件，可以根據這些特徵進行路由轉發：
完整參考官方文件：https://istio.io/latest/docs/reference/config/networking/virtual-service/
2.1.2 流量轉發實現
基於上述的策略模型，如果你想配置如下：請求的header 帶有 username=brand 或者 dep=A1025 的時候，將流量轉發到服務的v1版本，否著轉發到default版本。
則策略程式碼如下：
# 說明：VirtualService 流量染色，根據不同的條件將流量發往不同特徵的版本中，假設這邊有default、v1、v2 版本
apiVersion: networking.istio.io/beta
kind: VirtualService
metadata:
name: router-test-vs
spec:
hosts:
- router-test-vs # 排程router-test服務的流量
exportTo:
- "."
http: # 加各種路由條件，比如匹配人員、所屬部門進行路由
- match # 使用者匹配 brand，部門匹配 A1025 時
- headers:
username:
exact: brand
- headers:
department:
exact: A1025
route:
destination:
# todo 匹配條件的流量路由到對應的服務上，比如ServiceA-V1
route:
destination:
# todo 不匹配條件的流量路由到其他服務上，比如ServiceA-V2
3 總結
本文介紹了在Mesh場景下如何使用流量染色，來對不同特徵的流量進行分發的實現過程。流量染色在我們實際的生產環境中可以有很多收益和價值：
- 支撐分級釋出，避免全量釋出時出現問題
- 支援染色實驗，讓部分人進入實驗環境
- QA的線上問題分析、驗證、除錯，甚至壓測