*作者：十眠*

## 什麼是全鏈路灰度？

微服務體系架構中，服務之間的依賴關係錯綜複雜，有時某個功能發版依賴多個服務同時升級上線。我們希望可以對這些服務的新版本同時進行小流量灰度驗證，這就是微服務架構中特有的全鏈路灰度場景，透過構建從閘道器到整個後端服務的環境隔離來對多個不同版本的服務進行灰度驗證。

點選下方連結，檢視直播教程：

<https:>

在釋出過程中，我們只需部署服務的灰度版本，流量在呼叫鏈路上流轉時，由流經的閘道器、各個中介軟體以及各個微服務來識別灰度流量，並動態轉發至對應服務的灰度版本。如下圖：

![1.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/ec03fca844de49c4a3dffbf8ab70a82e~tplv-k3u1fbpfcp-zoom-1.image "1.png")

上圖可以很好展示這種方案的效果，我們用不同的顏色來表示不同版本的灰度流量，可以看出無論是微服務閘道器還是微服務本身都需要識別流量，根據治理規則做出動態決策。當服務版本發生變化時，這個呼叫鏈路的轉發也會實時改變。相比於利用機器搭建的灰度環境，這種方案不僅可以節省大量的機器成本和運維人力，而且可以幫助開發者實時快速的對線上流量進行精細化的全鏈路控制。

## OpenSergo[1] 流量路由標準

> Q：OpenSergo是什麼？

> A：OpenSergo 是一套開放、通用的、面向分散式服務架構、覆蓋全鏈路異構化生態的服務治理標準，基於業界服務治理場景與實踐形成服務治理通用標準。OpenSergo 的最大特點是**以統一的一套配置/DSL/協議定義服務治理規則，面向多語言異構化架構，做到全鏈路生態覆蓋**。無論微服務的語言是Java, Go, Node.js還是其它語言，無論是標準微服務還是 Mesh 接入，從閘道器到微服務，從資料庫到快取，從服務註冊發現到配置，開發者都可以透過同一套OpenSergo CRD標準配置針對每一層進行統一的治理管控，而無需關注各框架、語言的差異點，降低異構化、全鏈路服務治理管控的複雜度
> 
>
> Q：為什麼瞭解全鏈路灰度之前先給我介紹 OpenSergo？
> A：OpenSergo 定義了一套統一的 YAML 配置方式來針對分散式架構進行全鏈路的服務治理的規範，介紹規範與標準的同時，我們可以瞭解其中的技術細節的實現，同時我們還可以將新的元件與 OpenSergo 的標準進行實現。

流量路由，顧名思義就是將具有某些屬性特徵的流量，路由到指定的目標。流量路由是流量治理中重要的一環，開發者可以基於流量路由標準來實現各種場景，如灰度釋出、金絲雀釋出、容災路由、標籤路由等。

全鏈路灰度示例：

![2.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/b315977c762248ab8297a0733c150d9e~tplv-k3u1fbpfcp-zoom-1.image "2.png")

流量路由規則(v1alpha1) 主要分為三部分：

-   Workload 標籤規則 (WorkloadLabelRule)：將某一組 workload 打上對應的標籤，這一塊可以理解為是為應用或者對應儲存層的話就是資料庫負載（資料庫、表）打上對應的標籤
-   流量標籤規則 (TrafficLabelRule)：將具有某些屬性特徵的流量，打上對應的標籤
-   按照 Workload 標籤和流量標籤來做匹配路由，將帶有指定標籤的流量路由到匹配的 workload 中

### 給流量打標：

需要將具有某些屬性特徵的流量，打上對應的標籤。

假設現在需要將深圳地域的使用者灰度到新版主頁，測試使用者 location=cn-shenzhen，cn-shenzhen 位於 location header 中：

```
apiVersion: traffic.opensergo.io/v1alpha1
kind: TrafficLabelRule
metadata:
  name: my-traffic-label-rule
  labels:
    app: spring-cloud-zuul
spec:
  selector:
    app: spring-cloud-zuul
  trafficLabel: gray
  match:
  - condition: "=="    # 匹配表示式
    type: header       # 匹配屬性型別
    key: 'location'   # 引數名
    value: cn-shenzhen       # 引數值
```

透過上述配置，location header 為 cn-shenzhen 的 HTTP 流量，打上 gray 標，代表這個流量為灰度流量。

### 給 Workload 打標籤：

在使用 Nacos 作為服務發現的業務系統中，一般是需要業務根據其使用的微服務框架來決定打標方式。如果 Java 應用使用的 Spring Cloud 微服務開發框架，我們可以為業務容器新增對應的環境變數來完成標籤的新增操作。比如我們希望為節點新增版本灰度標，那麼為業務容器新增  traffic.opensergo.io/label: gray ，這樣框架向 Nacos 註冊該節點時會為其新增一個 gray 標籤。

對於一些複雜的 workload 打標場景（如資料庫例項、快取例項標籤），我們可以利用 WorkloadLabelRule CRD 進行打標。示例：

```
apiVersion: traffic.opensergo.io/v1alpha1
kind: WorkloadLabelRule
metadata:
  name: gray-sts-label-rule
spec:
  workloadLabels: ['gray']
  selector:
    db: mse-demo
    table: mse_demo_table_gray
```

## 全鏈路灰度在資料庫上的常見方案

### 方案一：影子庫

每個單獨維護一套獨立的庫，假設基線環境的庫的名稱為 mse-demo，那麼 gray 環境的流量可以對映到 mse-demo-gray 的庫中，我們在同一個例項上建立對應環境流量的影子庫，我們在業務中維護著各個庫連線的連線池，根據不同的流量標選擇對應的影子庫的連線去訪問，以此達到資料和基線環境庫隔離的效果，從而避免了灰度環境流量產生的資料對基線環境庫造成汙染。

### 方案二：影子表

類似影子庫方案，針對影子表方案，是在同一個例項上的同一個資料庫上建立對應的影子表。我們在執行 SQL 的過程中，對灰度流量的 SQL 進行解析與修改，實現不同環境流量的 SQL 分別訪問對應的表，假設基線環境的表的名稱為 mse_demo_table，那麼 gray 環境的流量可以對映到 mse_demo_table_gray 的表中。從而實現灰度資料和基線環境資料表隔離的效果。

## MSE[2] 資料庫全鏈路灰度能力

MSE 提供了一種資料隔離的方案，您可以在不需要修改任何業務程式碼的情況下，實現資料庫層面全鏈路灰度。下面介紹 MSE 基於 Mysql 資料儲存透過影子表的方案實現全鏈路灰度的能力。

### 前提條件

-   應用接入 MSE
-   部署 Demo 應用

在阿里雲容器服務中部署 A、B、C 三個應用，每個應用分別部署⼀個 base 版本和⼀個 gray 版本；並部署⼀個 Nacos Server 應用，用於實現服務發現。具體可參考教程完成應用部署：部署 Demo 應用程式 **[3** **]** 。

![3.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/5061279e97ac45db915707d23daa26c0~tplv-k3u1fbpfcp-zoom-1.image "3.png")

Demo 應用介紹，本 Demo 中的 C 應用會向資料庫執行如下語句：

```
CREATE TABLE `mse_demo_table` (
  `id` int NOT NULL AUTO_INCREMENT,
  `location` varchar(255) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8mb3
```

其中涉及到的資料庫建表語句：

```
CREATE TABLE `mse_demo_table` (
  `id` int NOT NULL AUTO_INCREMENT,
  `location` varchar(255) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8mb3
```

-   建立影子表，我們 Demo涉及到的資料庫表有 mse_demo_table，因為我們需要建立灰度 gray 環境，因此我們需要提前建立 mse_demo_table_gray 表。

```
CREATE TABLE `mse_demo_table_gray` (
  `id` int NOT NULL AUTO_INCREMENT,
  `location` varchar(255) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8mb3
;
```

### 第一步：配置全鏈路灰度規則

您需要配置完成 MSE 的全鏈路釋出，具體操作細節可參考教程：配置全鏈路灰度 **[** **4]** 。

建立如下泳道規則：

![4.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/67c489adda834e278fdd12474ca71f38~tplv-k3u1fbpfcp-zoom-1.image "4.png")

### 第二步：配置資料庫全鏈路灰度

-   我們需要配置以下環境變數來額外開啟/配置資料庫的全鏈路灰度能力

![5.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/9e3066214cbf4f38be4725fdc0172cf6~tplv-k3u1fbpfcp-zoom-1.image "5.png")

### 第三步：結果驗證

我們發起灰度請求，發現流量請求均訪問灰度環境：

```
curl -H "location: cn-shenzhen" http://106.14.XX.XX/a
Agray[172.18.XX.XX] -> Bgray[172.18.XX.XX] -> Cgray[172.18.XX.XX]%
```

我們透過如下 SQL 查詢影子表：

```
SELECT * FROM `mse_demo_table_gray`
```

發現灰度環境的資料都插入至影子表。

## 不僅僅是全鏈路灰度

目前為止 MSE 服務治理全鏈路灰度能力已經支援了雲原生閘道器、ALB、APISIX、Apache Dubbo、Spring Cloud、RocketMQ 以及資料庫。在資料庫層面我們透過影子表的方式實現了資料層面的流量隔離，下一步我們會將該能力進行進一步產品化，全鏈路灰度也會支援快取層面的能力。

服務治理是微服務改造深入到一定階段之後的必經之路，在這個過程中我們不斷有新的問題出現。

-   除了全鏈路灰度，服務治理還有沒其他能力？
-   服務治理能力有沒一個標準的定義，服務治理能力包含哪些？
-   多語言場景下，有無全鏈路的最佳實踐或者標準？
-   異構微服務如何可以統一治理？

當我們在探索服務治理的過程中，我們在對接其他微服務的時候，我們發現治理體系不同造成的困擾是巨大的，打通兩套甚者是多套治理體系的成本也是巨大的。為此我們提出了 OpenSergo 專案。OpenSergo 要解決的是不同框架、不同語言在微服務治理上的概念碎片化、無法互通的問題。

OpenSergo 社群也在聯合各個社群進行進一步的合作，社群來一起討論與定義統一的服務治理標準。當前社群也在聯合 bilibili、位元組跳動等企業一起共建標準，也歡迎感興趣的開發者、社群與企業一起加入到 OpenSergo 服務治理標準共建中。歡迎大家加入 OpenSergo 社群交流群（釘釘群）進行討論：34826335

***參考連結：***

*[1] OpenSergo：*

*<https:>*

*[2] MSE 微服務引擎：*

*<https:>*

*[3] 部署Demo 應用程式：*

*<https:>*

*[4] 配置全鏈路灰度：*

*<https:>*

MSE 註冊配置中心專業版首購享 9 折優惠，MSE 雲原生閘道器預付費全規格享 9 折優惠。點選[此處](https://www.aliyun.com/product/aliware/mse)，即享優惠！</https:></https:></https:></https:></https:>

全鏈路灰度在資料庫上我們是怎麼做的？

相關文章