什么是全鏈路灰度？

微服務(wù)體系架構(gòu)中，服務(wù)之間的依賴關(guān)系錯綜復(fù)雜，有時某個功能發(fā)版依賴多個服務(wù)同時升級上線。我們希望可以對這些服務(wù)的新版本同時進行小流量灰度驗證，這就是微服務(wù)架構(gòu)中特有的全鏈路灰度場景，通過構(gòu)建從網(wǎng)關(guān)到整個后端服務(wù)的環(huán)境隔離來對多個不同版本的服務(wù)進行灰度驗證。

查看直播教程：?https://yqh.aliyun.com/live/detail/29004?

在發(fā)布過程中，我們只需部署服務(wù)的灰度版本，流量在調(diào)用鏈路上流轉(zhuǎn)時，由流經(jīng)的網(wǎng)關(guān)、各個中間件以及各個微服務(wù)來識別灰度流量，并動態(tài)轉(zhuǎn)發(fā)至對應(yīng)服務(wù)的灰度版本。如下圖：

上圖可以很好展示這種方案的效果，我們用不同的顏色來表示不同版本的灰度流量，可以看出無論是微服務(wù)網(wǎng)關(guān)還是微服務(wù)本身都需要識別流量，根據(jù)治理規(guī)則做出動態(tài)決策。當服務(wù)版本發(fā)生變化時，這個調(diào)用鏈路的轉(zhuǎn)發(fā)也會實時改變。相比于利用機器搭建的灰度環(huán)境，這種方案不僅可以節(jié)省大量的機器成本和運維人力，而且可以幫助開發(fā)者實時快速的對線上流量進行精細化的全鏈路控制。

OpenSergo[1] 流量路由標準

Q：OpenSergo是什么？

A：OpenSergo 是一套開放、通用的、面向分布式服務(wù)架構(gòu)、覆蓋全鏈路異構(gòu)化生態(tài)的服務(wù)治理標準，基于業(yè)界服務(wù)治理場景與實踐形成服務(wù)治理通用標準。OpenSergo 的最大特點是以統(tǒng)一的一套配置/DSL/協(xié)議定義服務(wù)治理規(guī)則，面向多語言異構(gòu)化架構(gòu)，做到全鏈路生態(tài)覆蓋。無論微服務(wù)的語言是Java, Go, Node.js還是其它語言，無論是標準微服務(wù)還是 Mesh 接入，從網(wǎng)關(guān)到微服務(wù)，從數(shù)據(jù)庫到緩存，從服務(wù)注冊發(fā)現(xiàn)到配置，開發(fā)者都可以通過同一套OpenSergo CRD標準配置針對每一層進行統(tǒng)一的治理管控，而無需關(guān)注各框架、語言的差異點，降低異構(gòu)化、全鏈路服務(wù)治理管控的復(fù)雜度

Q：為什么了解全鏈路灰度之前先給我介紹 OpenSergo？

A：OpenSergo 定義了一套統(tǒng)一的 YAML 配置方式來針對分布式架構(gòu)進行全鏈路的服務(wù)治理的規(guī)范，介紹規(guī)范與標準的同時，我們可以了解其中的技術(shù)細節(jié)的實現(xiàn)，同時我們還可以將新的組件與 OpenSergo 的標準進行實現(xiàn)。

流量路由，顧名思義就是將具有某些屬性特征的流量，路由到指定的目標。流量路由是流量治理中重要的一環(huán)，開發(fā)者可以基于流量路由標準來實現(xiàn)各種場景，如灰度發(fā)布、金絲雀發(fā)布、容災(zāi)路由、標簽路由等。

全鏈路灰度示例：

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

• Workload 標簽規(guī)則 (WorkloadLabelRule)：將某一組 workload 打上對應(yīng)的標簽，這一塊可以理解為是為應(yīng)用或者對應(yīng)存儲層的話就是數(shù)據(jù)庫負載（數(shù)據(jù)庫、表）打上對應(yīng)的標簽
• 流量標簽規(guī)則 (TrafficLabelRule)：將具有某些屬性特征的流量，打上對應(yīng)的標簽
• 按照 Workload 標簽和流量標簽來做匹配路由，將帶有指定標簽的流量路由到匹配的 workload 中

給流量打標：

需要將具有某些屬性特征的流量，打上對應(yīng)的標簽。

假設(shè)現(xiàn)在需要將深圳地域的用戶灰度到新版主頁，測試用戶 locatinotallow=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'   # 參數(shù)名
    value: cn-shenzhen       # 參數(shù)值

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

給 Workload 打標簽：

在使用 Nacos 作為服務(wù)發(fā)現(xiàn)的業(yè)務(wù)系統(tǒng)中，一般是需要業(yè)務(wù)根據(jù)其使用的微服務(wù)框架來決定打標方式。如果 Java 應(yīng)用使用的 Spring Cloud 微服務(wù)開發(fā)框架，我們可以為業(yè)務(wù)容器添加對應(yīng)的環(huán)境變量來完成標簽的添加操作。比如我們希望為節(jié)點添加版本灰度標，那么為業(yè)務(wù)容器添加
http://traffic.opensergo.io/label: gray ，這樣框架向 Nacos 注冊該節(jié)點時會為其添加一個 gray 標簽。

對于一些復(fù)雜的 workload 打標場景（如數(shù)據(jù)庫實例、緩存實例標簽），我們可以利用 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

全鏈路灰度在數(shù)據(jù)庫上的常見方案

方案一：影子庫

每個單獨維護一套獨立的庫，假設(shè)基線環(huán)境的庫的名稱為 mse-demo，那么 gray 環(huán)境的流量可以映射到 mse-demo-gray 的庫中，我們在同一個實例上建立對應(yīng)環(huán)境流量的影子庫，我們在業(yè)務(wù)中維護著各個庫連接的連接池，根據(jù)不同的流量標選擇對應(yīng)的影子庫的連接去訪問，以此達到數(shù)據(jù)和基線環(huán)境庫隔離的效果，從而避免了灰度環(huán)境流量產(chǎn)生的數(shù)據(jù)對基線環(huán)境庫造成污染。

方案二：影子表

類似影子庫方案，針對影子表方案，是在同一個實例上的同一個數(shù)據(jù)庫上建立對應(yīng)的影子表。我們在執(zhí)行 SQL 的過程中，對灰度流量的 SQL 進行解析與修改，實現(xiàn)不同環(huán)境流量的 SQL 分別訪問對應(yīng)的表，假設(shè)基線環(huán)境的表的名稱為 mse_demo_table，那么 gray 環(huán)境的流量可以映射到 mse_demo_table_gray 的表中。從而實現(xiàn)灰度數(shù)據(jù)和基線環(huán)境數(shù)據(jù)表隔離的效果。

MSE[2] 數(shù)據(jù)庫全鏈路灰度能力

MSE 提供了一種數(shù)據(jù)隔離的方案，您可以在不需要修改任何業(yè)務(wù)代碼的情況下，實現(xiàn)數(shù)據(jù)庫層面全鏈路灰度。下面介紹 MSE 基于 Mysql 數(shù)據(jù)存儲通過影子表的方案實現(xiàn)全鏈路灰度的能力。

前提條件

• 應(yīng)用接入 MSE
• 部署 Demo 應(yīng)用

在阿里云容器服務(wù)中部署 A、B、C 三個應(yīng)用，每個應(yīng)用分別部署?個 base 版本和?個 gray 版本；并部署?個 Nacos Server 應(yīng)用，用于實現(xiàn)服務(wù)發(fā)現(xiàn)。具體可參考教程完成應(yīng)用部署：部署 Demo 應(yīng)用程序[3]。

Demo 應(yīng)用介紹，本 Demo 中的 C 應(yīng)用會向數(shù)據(jù)庫執(zhí)行如下語句：

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

其中涉及到的數(shù)據(jù)庫建表語句：

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

• 創(chuàng)建影子表，我們 Demo涉及到的數(shù)據(jù)庫表有 mse_demo_table，因為我們需要創(chuàng)建灰度 gray 環(huán)境，因此我們需要提前創(chuàng)建 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
;

第一步：配置全鏈路灰度規(guī)則

您需要配置完成 MSE 的全鏈路發(fā)布，具體操作細節(jié)可參考教程：配置全鏈路灰度[4]。

創(chuàng)建如下泳道規(guī)則：

第二步：配置數(shù)據(jù)庫全鏈路灰度

• 我們需要配置以下環(huán)境變量來額外開啟/配置數(shù)據(jù)庫的全鏈路灰度能力

第三步：結(jié)果驗證

我們發(fā)起灰度請求，發(fā)現(xiàn)流量請求均訪問灰度環(huán)境：

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`

發(fā)現(xiàn)灰度環(huán)境的數(shù)據(jù)都插入至影子表。

不僅僅是全鏈路灰度

目前為止 MSE 服務(wù)治理全鏈路灰度能力已經(jīng)支持了云原生網(wǎng)關(guān)、ALB、APISIX、Apache Dubbo、Spring Cloud、RocketMQ 以及數(shù)據(jù)庫。在數(shù)據(jù)庫層面我們通過影子表的方式實現(xiàn)了數(shù)據(jù)層面的流量隔離，下一步我們會將該能力進行進一步產(chǎn)品化，全鏈路灰度也會支持緩存層面的能力。

服務(wù)治理是微服務(wù)改造深入到一定階段之后的必經(jīng)之路，在這個過程中我們不斷有新的問題出現(xiàn)。

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

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