作者：至簡

軟體是以持續迭代的方式去不斷演進的。某種程度上，我們並不擔心軟體不完善，但擔心軟體的迭代速度太慢而影響了完善的速度。在分散式軟體領域，如何快速、安全地驗證新的軟體版本一直是大家所關心並探索的。服務網格（Service Mesh）的出現將這個領域的探索推向了新的高度。“泳道”這一概念在分散式軟體領域並非新詞，只不過，這次我們是以服務網格為基礎技術去構建，充分發揮雲原生技術天然具備靈活治理流量的優勢。
本文分享了阿里雲內部所沉澱的全鏈路流量打標與路由的能力，做出服務網格技術新體驗的同時，很好地兌現了服務網格的新價值。

## 概念與場景

圖 1 以 Istio 官方所提供的 Bookinfo 示例程式為例示例說明了使用場景中的關鍵概念。其中紫色的圓邊方框代表了 Envoy。圖中所有泳道的性質是一樣的，不同的命名只是為了區分細分場景或使用者。

• 基線（baseline）：指業務所有服務都部署到了這一環境中。基線可以來自真實的生產環境，也可以專為開發工作而構建的與生產環境完全獨立的環境。

• 流量泳道（traffic lane）：代表了一個與基線環境相隔離的軟環境，透過給機器（即 Kubernetes 中的 Pod）打標籤的方法，將機器加入到該泳道中。顯然，加入泳道的機器在網路層面與基線中的機器是互通的。

• 流量回退（traffic fallback）：泳道中所部署的服務數量並非要求與基線環境完全一致，當泳道中並不存在呼叫鏈中所依賴的其他服務時，流量需要回退至基線環境，進一步在必要的時候返流泳道。比如，圖 1 中 dev1 泳道中並不存在 productpage 服務所依賴的 reviews 服務，因此需要讓流量回退到基線中的 reviews 服務（圖中深藍色線所示），緊接著基線中的 reviews 服務需要將流量打回 dev1 泳道中的 ratings 服務。

• 流量標識透傳（traffic label passthrough）：所有服務邊上的 Sidecar 都需要有能力將調入請求中所攜帶的流量標籤自動放到由這一請求所分叉出的每一個調出請求中去，以便實現全鏈路流量標識透傳和按流量標識路由，否則泳道與基線間的流量無法來回穿梭。
• 入口服務（entrance service）：指流量進入泳道時所觸達的第一個服務。圖 1 中代表服務的圖形在左邊框邊上打上三角形標識的就代表它是一個入口服務。

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/7c8e4cb23b0946a5bcdb656815a5b23b.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center)

圖1

泳道技術可以運用於如下場景：

• 單個服務的日常開發或多個服務間的日常開發聯調。開發者建立泳道，將增加了新功能的服務部署到泳道中，基於流量的特徵透過定義規則將測試流量引入泳道中進行驗證。由於泳道只需部署被測試服務的新版本，省去了搭建全鏈路測試環境的麻煩。在這一場景中，需要注意測試流量所存在的資料落盤問題，處理好開發與聯調過程中所留下的髒資料。

• 全鏈路灰度。對於涉及重大功能上線中的多個服務，可以透過泳道以全鏈路灰度的方式做更為全面的功能驗證。全鏈路功能驗收透過後，再將服務的新版本釋出至基線。

• 關鍵業務重保。類似零售場景的業務（比如 POS 機收銀），我們不希望因為軟體的故障而引發巨大的輿情，這時可以透過泳道對業務流量進行隔離實現重保。

## 技術實現
 ###  流量打標方案與實現
 
在運用泳道技術時，根據流量打標的位置不同而存在三種不同的方案。值得指出，雖然方案有所不同，但就服務網格而言的技術實現是完全一致的，將方案羅列出來是為了幫助讀者更好地理解。

圖 2 示例說明了方案一。在這個方案中，流量進入服務網格的 Ingress 閘道器之前還有一級閘道器，我們姑且稱之為 API 閘道器（比如，Nginx）。通常 API 閘道器可以根據流量的特徵，在轉發收到的請求前先加上額外的頭，從而完成對流量的打標動作。圖中對於特定的流量將增加名為 x-asm-traffic-lane: dev1 的 HTTP 頭，代表需要將流量打到 dev1 泳道中。在這個方案，服務網格中的 Envoy 無需有任何流量打標動作。

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/6b561f45273b474baefd946e12bea941.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center)

圖 2

圖 3 示例說明了方案二。本方案中，客戶端的流量直接打到服務網格的 Ingress 閘道器上。由 Ingress 閘道器根據流量的特徵透過 Istio 原生的 VirtualService 匹配規則識別出後，在轉發請求前加上名為 x-asm-traffic-lane 的 HTTP 頭，隨後將流量路由到相應的泳道。

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/d3932a102aee466aba5df94bf1225d63.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center)

圖 3

圖 4 示例說明了方案三。本質上，這一方案與方案二是完全一樣的，同樣透過 Istio 原生的 VirtualService 匹配規則識別出相應的流量後加上名為 x-asm-traffic-lane 的 HTTP 頭。唯一的不同在於，方案二中的 Envoy 的角色是 Ingress，而方案三中 Envoy 的角色是 Sidecar。
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/bd01d36cd09e437a8bf473f599ef0e2a.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center)

圖 4

流量一旦完成打標後，由服務網格中的每一個 Envoy 基於流量標和控制面下發的配置做全鏈路的標透傳和按標路由。

###  流量標識透傳
圖 5 示例說明了服務網格中一個服務與邊上的 Envoy (Sidecar）間的流量細節。
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/d0e656eca2a24c53898d74afe3332dc1.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center)
圖 5

從 Envoy 的視角來看，包含對流入和流出兩種流量的轉發。I1 是流入的流量，收到後將轉發給本地的 Svc A；O1 是流出的流量（因為處理 l1 的需要而去呼叫別的服務所引發），收到後將轉發給外部的被呼叫的服務。流入與流出只與請求（request）相關，與請求對應的響應（response）沒有關係。顯然，一個流入的請求可能導致有多個流出的請求發生（即“分叉”），這完全取決於 Svc A 的具體業務邏輯。

泳道技術所需解決的核心點在於，當流入的流量打上了相應的標籤後，如何讓由其所分叉出的每一個流出的流量都帶上同樣的標籤，我們採用的方案是結合鏈路追蹤技術（比如，OpenTelemetry）去解決。鏈路追蹤技術是透過 traceId 去唯一標識一條呼叫鏈樹，為根請求分配並帶上全網唯一的 traceId 後，之後由其所分叉出的所有新呼叫都得帶上值完全一樣的 HTTP 頭，換句話說服務開發者需要在程式設計的過程中確保這一頭被傳播到後續的服務呼叫中（比如，呼叫 OpenTelemetry 的 SDK 完成頭傳播）。換句話說，運用泳道技術的前提是需要每個服務都採用了鏈路追蹤技術，作為微服務構架的最佳實踐之一這一先決條件很容易滿足。回到圖 5，Svc A 收到 I2 請求並對之處理時需要發起 O1 呼叫，此時需要確保 I2 中的 traceId 頭傳播到 O1 請求中，這是 Svc A 的開發者需要特別注意的一個細節。

一旦服務網格中所有服務的請求都帶上了 traceId，那麼透過 Envoy 實現全鏈路的流量標透傳就是非常簡單的事了。大體分這幾大步驟：

• Envoy 內部構建一張對映表，記錄 traceId 與流量標的對映。比如，圖 5 所示的流量標是放在 x-asm-traffic-lane 這一 HTTP 頭中的。x-asm-traffic-lane: dev1 代表的流量標是 dev1，x-asm-traffic-lane: canary 代表的流量標是 canary。
• 當請求 I1 進到 Envoy 時，Envoy 基於請求中所帶的 traceId 和流量標，在對映表中增加一條對映記錄。
• Envoy 對於收到的每一個 O1 請求，基於請求中的 traceId 從對映表中找到對應的流量標並將之增加到 O2 請求中再轉發出去。

透過服務網格基於 traceId 打標的技術方案的好處在於，將流量打標的動作和流量標傳遞做到完全與服務解耦，將這一能力下沉到本來擅長流量治理的服務網格中，讓流量排程的靈動性得以進一步解鎖。

### 流量標識與 traceld 的定義
我們在 Istio 已有 CR 的基礎上，新增了 TrafficLabel 這個全新的 CRD。選擇新增而非直接對 VirtualService 做擴充套件的原因是，VirtualService 的設計之初是應用維度的，當一個業務複雜到全鏈路有很多應用需要放到泳道中時，就得對每個應用的 VirtualService 進行變更，背後所導致的時效性和可操作性會是一個問題。擴充套件 VirtualService 去實現的另一種思路是，讓 VirtualService 具備配置全域性規則的能力，而這就要用到規則的合併機制，這一點從實操層面也有問題。Istio 社群對於多個 VirtualService 進行合併的需求有不少討論，目前只在閘道器上支援合併，對於 Sidecar 則不提供這一能力，原因在於擔心合併的順序不同而導致故障。

圖 6 示例說明了如何使用 TrafficLabel 這一 CR 在 istio-system 根名稱空間定義全域性有效的流量打標方法。其中定義了名為 x-asm-traffic-lane 的標籤，作為 HTTP 請求的頭用於存放流量標識（比如，dev1、dev2、canary 等），以及 traceId 基於 x-request-id 獲得。使用者可以根據自己所選型的鏈路追蹤系統的具體實現加以設定。圖中設定為從 x-request-id 頭中獲得，是因為 Envoy 實現了透過 x-request-id 做全網鏈路唯一性標識的功能。採用 x-request-id 作為對映表鍵意味著，我們可以直接用 Istio 開源社群所提供的 Bookinfo 示例程式去演示泳道的效果，因為 Bookinfo 中的所有服務都做了 x-request-id 頭從調入請求到調出請求的傳播。

```css
apiVersion: istio.alibabacloud.com/v1beta1
kind: TrafficLabel
metadata:
  name: global-traffic-label
spec:
  rules:
  - labels:
      - name: x-asm-traffic-lane
    protocols: "http"
    traceIdHeader: x-request-id
  hosts:
    - "*"
```

圖6

### 按流量標路由
為了支援按流量標路由，需要對 Istio 的 VirtualService 做擴充套件，讓 destination 欄位支援用 $x-asm-traffic-lane 這樣的變數指定流量的目的地，如下圖 7 所示。換句話說，包含 x-asm-traffic-lane: dev2 頭的流量會打到 dev2 這個泳道中，背後其實是使用 DestinationRule 定義的名為 dev2 的 subset，如圖 8 所示。請注意，圖 7 中 VirtualService 中的 $x-asm-traffic-lane 這一名稱要與圖 6 中 TrafficLabel 內所定義的名保持一致。

```css
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
    - reviews
  http:
  - match:
    - headers:
        end-user:
          exact: dev2
    route:
    - destination:
        host: reviews
        subset: dev2
      fallback:
        case: noinstances|notavailable
        target:
          host: reviews
          subset: baseline
      headers:
        request:
          set:
            x-asm-traffic-lane: dev2
  - route:
    - destination:
        host: reviews
        subset: $x-asm-traffic-lane
      fallback:
        case: noinstances|notavailable
        target:
          host: reviews
          subset: baseline
  - route:
    - destination:
        host: reviews
        subset: baseline
```

圖7

```css
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  subsets:
  - labels:
      version: v2
    name: baseline
  - labels:
      version: v3
    name: dev2
```

圖8

從圖 8 中 DestinationRule 的定義不難看出，除了 baseline 外只定義了 dev2 這個泳道，圖 7 則是對應情形下的 VirtualService 定義。兩者對應的使用場景正是圖 1 中的基線和 dev2 泳道。

## 產品實現

在雲原生的大技術背景之下，易用性被放到了聚光燈之下，我們深刻理解背後意味著什麼。為此，在設計產品的互動時，努力清空自己所知、站在使用者所面臨的場景下去思考和最佳化，在功能性和易用性之間努力做好平衡。

在使用者使用泳道前，我們認為他已構建了一個包含所有服務在內的基線環境。在 K8s 中，基線環境通常被部署於特定的名稱空間中以便更好地運維和管理其中的服務。使用者建立泳道時，只需提供泳道名稱。本節接下來的內容以建立名為 dev2 的泳道展開。
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/4f27d2804b6e4e16a215835bd9e24c2f.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center)

泳道建立好後，需要將服務釋出到泳道之中。由於所釋出的服務已存於基線環境中並建立了 K8s Service 資源，所以泳道中釋出服務其實是建立對應服務下的一個 Deployment，直觀的理解就是建立已有服務的另一個軟體版本。不難想到，這一發布動作包含確認基線版本，例項數和容器映象地址。

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/ae79b23562484cda82842d75f4156e7d.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center)

當服務釋出到泳道中後，需要透過泳道的服務列表確保所有服務都正常啟動。此時泳道中並沒有流量進入，需要透過配置引流規則才能將基線中的流量引入泳道中。

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/f07b8bb29f6e4defbb7c110af5fed28e.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center)

引流規則可以基於 HTTP 頭、URI、Cookie 的特徵去配置，方便我們精確地選擇被測流量進入泳道。下圖的規則是指將 HTTP 頭 end-user 的值為 dev2 的流量引導致 dev2 泳道中。配置規則的同時，需要正確指定入口服務。

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/3f1cb7fbc42f4888a134aaa905fdeb4d.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center)

引流規則應用後，即可在網頁上以 dev2 使用者名稱登入，從而看到 dev2 泳道中服務所呈現的效果。下面兩圖分別示例了全基線和 dev2 泳道所看到的頁面效果。由於 dev2 泳道中並沒有部署 productpage 和 details 兩個服務，所以這兩個服務會回退為使用基線中的，而最終呈現的效果就是兩圖中 The Comedy of Errors 和 Book Details 兩塊的內容是完全一致的。
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/3d2eedfa82df45e8b8987e828463015c.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center)
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/c90a5e7eebad421fb5c673e9928f824e.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center)

當服務釋出到泳道中上線後，可以在泳道的服務列表中方便地檢視各服務與基線版本的流量比對情況。幫助開發者更好地瞭解泳道中服務的執行情況。

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/727d72f0315a46c6b2f6b6d865efc830.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center)

此外，透過服務拓撲圖也可以清晰地看到，dev2 泳道中服務的呼叫情況（圖中的 lane-dev2）。
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/0220aa80e7ca4fda8b310d7aad09dc45.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center)

## 總結與展望
我們所探索的基於服務網格的泳道技術，讓開發者能秒級建立隔離環境用於開發測試或業務重保，透過精確的引流規則將“爆炸半徑”控制到最小。很好地兌現了雲原生服務網格技術的新體驗和新價值。

接下來，我們將進一步以場景化的方式打通泳道和版本灰度的功能，讓使用者能基於直覺使用好這些功能。功能層面，我們將進一步完善泳道中支援的協議，比如 RocketMQ、Dubbo 3.0 等，透過豐富泳道技術的應用場景去最大程度地發揮其價值。

最後，我們將持續以 Service Mesh as Infra 的理念去構建微服務架構的現代化服務治理平臺，和業界夥伴一同加速這一新技術的發展和推廣。

作者介紹：李雲（花名：至簡），阿里雲服務網格混合雲產品技術負責人。2018 年開始在阿里集團帶領團隊從事服務網格技術的發展與建設工作，在 QCon 做過多次雲原生與服務網格的技術分享。

兌現 Service Mesh 的新價值：精確控制“爆炸半徑”

相關文章