★ 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的線上問題分析、驗證、除錯,甚至壓測