★微服務系列

微服務1：微服務及其演進史
 微服務2：微服務全景架構
 微服務3：微服務拆分策略
 微服務4：服務註冊與發現
 微服務5：服務註冊與發現（實踐篇）
微服務6：通訊之閘道器
 微服務7：通訊之RPC
微服務8：通訊之RPC實踐篇（附原始碼）
微服務9：服務治理來保證高可用
 微服務10：系統服務熔斷、限流
 微服務11：熔斷、降級的Hystrix實現（附原始碼）

1 微服務的基本流量策略

微服務提供了一些技術來實現對微服務的流量的管理，其中最典型的就是對流量進行拆分和轉發。
具體體現在金絲雀釋出（灰度釋出）、ABTesting 以及流量染色等策略方案上，下面會進行詳細的介紹。

2 價值和必要性

★ 價值驅動：

支援藍綠髮布、金絲雀釋出，無需停服也能保證釋出的無縫銜接，提高了服務整體的SLA。
全鏈路的ABTesting，保證不同特徵型別的使用者可以在獨立的鏈路通道上測試、使用、實驗、生產。
大幅降低早期為實現灰度而做多服務的資源（時間、伺服器資源）損耗。

★ 業務視角：

實現所有業務分級釋出、擴散發布的能力，保證釋出的漸序性。比如上線一個新功能，首先在小範圍釋出，觀察一段時間之後在全量釋出。
染色實驗的各種場景，讓不同型別的使用者體驗不同型別的功能。
實現多環境場景的降本增效：無需再對不同環境的服務獨立部署，從維護和資源上來說，大大降低了成本。

3 流量調控

3.1 金絲雀釋出、ABTesting

這是流量排程中典型的金絲雀場景，可以先放行一部分流量轉發到一個新的服務範例中，這個新的服務範例只有你的研發和測試團隊可以接入。可以在上面嘗試使用或者測試，直到你確認你的服務是健康的，功能完整的，沒有bug的，再把流量逐漸的引流過去。
這個的好處是減少釋出新功能存在的風險，而且全程是無停服釋出，對使用者是透明無感知的，大大提高了可用性，提升服務SLA。

3.2 流量染色

流量染色也是一種典型的場景。如果你想讓不同的使用者群體(比如這邊的Group A、Group B、Group C)使用的功能也是不同的，那流量染色是一個不可缺少的功能。
它可以把符合某些特徵的使用者流量調控到對應的服務版本中。比如GroupA是學生群體，對應到V1版本，GroupB是政企員工群體，對應到V2版本。需要注意的是，如果是一條完整的鏈路，那鏈路上的各個服務包括資料儲存層都應該有不同的版本，這樣才能一一對應。

3.3 染色實現方案（以ServiceMesh為例子）

Mesh如果想要實現流量染色，需要具備以下幾個條件：

請求的流量中，需要附帶某些特徵，如流量的請求的Header、Cookies、queryParams等中帶有某些資訊。

Request Header：
UserId: 135648468
Dep: T204351
X-Request-Id: ee6637e816d7470bb2e90e13e1130733

部署在kubernetes上的服務（svc）的範例（pod）需要接入Mesh（如Istio），並在pod上打上版本標籤。

labels:
    app: traffic-test
    appName: traffic-test
    appType: java
    istio.io/rev: default
    pod-template-hash: 78ab8776a9
    security.istio.io/tlsMode: istio
    service.istio.io/canonical-revision: v1
    version: v1  #  在具體的 pod 中 label 上 v1 的 version 標籤

下發Istio的策略到kubernetes對應服務服務上：當請求的流量帶有某些特徵（如header中帶有Dep=SO）時，流量路由到對應標籤（如 version = v1 ）的服務範例上。

  spec:
    exportTo:
    - '*'
    host: xxx.com
    subsets:
    - labels:   #  這是v1 版本
        version: v1
      name: v1
      trafficPolicy:
        loadBalancer:
          simple: ROUND_ROBIN
    - labels:  # 這是default
        version: default
      name: default

header中符合帶Dep=T204351的走v1版本，不符合條件的路由則預設走到預設版本中（如 version = default）。

所以，Mesh的染色本質上是通過在流量中攜帶一些特徵（如流量的請求的Header、Cookies、queryParams等），而Mesh會根據這些請求的特徵進行路由匹配，轉發到對應的帶有某些特徵的服務範例上。
未匹配成功的流量則走到預設版本中，從而實現多個版本和跟預設版本的業務隔離的目標。

上面的圖，當部門編號為 T204351的時候，流量會轉發到服務的v1版本中；當部門編號為 T204352的時候，流量會轉發到服務的v2版本中；剩餘的流量，預設轉發到服務的default版本中。

4 總結

豐富的流量管理策略為我們系統的穩定性，以及流量的多樣化（金絲雀釋出、ABTesting、分級擴散流量、流量染色）使用提供了保證。

微服務12：流量策略