03

全鏈路灰度的解決方案

Cloud Native

如何在實(shí)際業(yè)務(wù)場(chǎng)景中去快速落地全鏈路灰度呢？目前，主要有兩種解決思路，基于物理環(huán)境隔離和基于邏輯環(huán)境隔離。
1
 物理環(huán)境隔離

物理環(huán)境隔離，顧名思義，通過(guò)增加機(jī)器的方式來(lái)搭建真正意義上的流量隔離。

這種方案需要為要灰度的服務(wù)搭建一套網(wǎng)絡(luò)隔離、資源獨(dú)立的環(huán)境，在其中部署服務(wù)的灰度版本。由于與正式環(huán)境隔離，正式環(huán)境中的其他服務(wù)無(wú)法訪問(wèn)到需要灰度的服務(wù)，所以需要在灰度環(huán)境中冗余部署這些線上服務(wù)，以便整個(gè)調(diào)用鏈路正常進(jìn)行流量轉(zhuǎn)發(fā)。此外，注冊(cè)中心等一些其他依賴的中間件組件也需要冗余部署在灰度環(huán)境中，保證微服務(wù)之間的可見(jiàn)性問(wèn)題，確保獲取的節(jié)點(diǎn) IP 地址只屬于當(dāng)前的網(wǎng)絡(luò)環(huán)境。

這個(gè)方案一般用于企業(yè)的測(cè)試、預(yù)發(fā)開(kāi)發(fā)環(huán)境的搭建，對(duì)于線上灰度發(fā)布引流的場(chǎng)景來(lái)說(shuō)其靈活性不夠。況且，微服務(wù)多版本的存在在微服務(wù)架構(gòu)中是家常便飯，需要為這些業(yè)務(wù)場(chǎng)景采用堆機(jī)器的方式來(lái)維護(hù)多套灰度環(huán)境。如果您的應(yīng)用數(shù)目過(guò)多的情況下，會(huì)造成運(yùn)維、機(jī)器成本過(guò)大，成本和代價(jià)遠(yuǎn)超收益；如果應(yīng)用數(shù)目很小，就兩三個(gè)應(yīng)用，這個(gè)方式還是很方便的，可以接受的。

2
 邏輯環(huán)境隔離

另一種方案是構(gòu)建邏輯上的環(huán)境隔離，我們只需部署服務(wù)的灰度版本，流量在調(diào)用鏈路上流轉(zhuǎn)時(shí)，由流經(jīng)的網(wǎng)關(guān)、各個(gè)中間件以及各個(gè)微服務(wù)來(lái)識(shí)別灰度流量，并動(dòng)態(tài)轉(zhuǎn)發(fā)至對(duì)應(yīng)服務(wù)的灰度版本。如下圖：

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

那么全鏈路灰度具體是如何實(shí)現(xiàn)呢？通過(guò)上面的討論，我們需要解決以下問(wèn)題：

1. 鏈路上各個(gè)組件和服務(wù)能夠根據(jù)請(qǐng)求流量特征進(jìn)行動(dòng)態(tài)路由
2. 需要對(duì)服務(wù)下的所有節(jié)點(diǎn)進(jìn)行分組，能夠區(qū)分版本

1. 需要對(duì)流量進(jìn)行灰度標(biāo)識(shí)、版本標(biāo)識(shí)
2. 需要識(shí)別出不同版本的灰度流量

接下來(lái)，會(huì)介紹解決上述問(wèn)題需要用到的技術(shù)。

標(biāo)簽路由

標(biāo)簽路由通過(guò)對(duì)服務(wù)下所有節(jié)點(diǎn)按照標(biāo)簽名和標(biāo)簽值不同進(jìn)行分組，使得訂閱該服務(wù)節(jié)點(diǎn)信息的服務(wù)消費(fèi)端可以按需訪問(wèn)該服務(wù)的某個(gè)分組，即所有節(jié)點(diǎn)的一個(gè)子集。服務(wù)消費(fèi)端可以使用服務(wù)提供者節(jié)點(diǎn)上的任何標(biāo)簽信息，根據(jù)所選標(biāo)簽的實(shí)際含義，消費(fèi)端可以將標(biāo)簽路由應(yīng)用到更多的業(yè)務(wù)場(chǎng)景中。

節(jié)點(diǎn)打標(biāo)

那么如何給服務(wù)節(jié)點(diǎn)添加不同的標(biāo)簽?zāi)?？在如今火熱的云原生技術(shù)推動(dòng)下，大多數(shù)業(yè)務(wù)都在積極進(jìn)行容器化改造之旅。這里，我就以容器化的應(yīng)用為例，介紹在使用 Kubernetes Service 作為服務(wù)發(fā)現(xiàn)和使用比較流行的 Nacos 注冊(cè)中心這兩種場(chǎng)景下如何對(duì)服務(wù) Workload 進(jìn)行節(jié)點(diǎn)打標(biāo)。

在使用 Kubernetes Service 作為服務(wù)發(fā)現(xiàn)的業(yè)務(wù)系統(tǒng)中，服務(wù)提供者通過(guò)向 ApiServer 提交 Service 資源完成服務(wù)暴露，服務(wù)消費(fèi)端監(jiān)聽(tīng)與該 Service 資源下關(guān)聯(lián)的 Endpoint 資源，從 Endpoint 資源中獲取關(guān)聯(lián)的業(yè)務(wù) Pod 資源，讀取上面的 Labels 數(shù)據(jù)并作為該節(jié)點(diǎn)的元數(shù)據(jù)信息。所以，我們只要在業(yè)務(wù)應(yīng)用描述資源 Deployment 中的 Pod 模板中為節(jié)點(diǎn)添加標(biāo)簽即可。

在使用 Nacos 作為服務(wù)發(fā)現(xiàn)的業(yè)務(wù)系統(tǒng)中，一般是需要業(yè)務(wù)根據(jù)其使用的微服務(wù)框架來(lái)決定打標(biāo)方式。如果 Java 應(yīng)用使用的 Spring Cloud 微服務(wù)開(kāi)發(fā)框架，我們可以為業(yè)務(wù)容器添加對(duì)應(yīng)的環(huán)境變量來(lái)完成標(biāo)簽的添加操作。比如我們希望為節(jié)點(diǎn)添加版本灰度標(biāo)，那么為業(yè)務(wù)容器添加`spring.cloud.nacos.discovery.metadata.version=gray`，這樣框架向Nacos注冊(cè)該節(jié)點(diǎn)時(shí)會(huì)為其添加一個(gè)標(biāo)簽`verison=gray`。

流量染色

請(qǐng)求鏈路上各個(gè)組件如何識(shí)別出不同的灰度流量？答案就是流量染色，為請(qǐng)求流量添加不同灰度標(biāo)識(shí)來(lái)方便區(qū)分。我們可以在請(qǐng)求的源頭上對(duì)流量進(jìn)行染色，前端在發(fā)起請(qǐng)求時(shí)根據(jù)用戶信息或者平臺(tái)信息的不同對(duì)流量進(jìn)行打標(biāo)。如果前端無(wú)法做到，我們也可以在微服務(wù)網(wǎng)關(guān)上對(duì)匹配特定路由規(guī)則的請(qǐng)求動(dòng)態(tài)添加流量標(biāo)識(shí)。此外，流量在鏈路中流經(jīng)灰度節(jié)點(diǎn)時(shí)，如果請(qǐng)求信息中不含有灰度標(biāo)識(shí)，需要自動(dòng)為其染色，接下來(lái)流量就可以在后續(xù)的流轉(zhuǎn)過(guò)程中優(yōu)先訪問(wèn)服務(wù)的灰度版本。

分布式鏈路追蹤

還有一個(gè)很重要的問(wèn)題是如何保證灰度標(biāo)識(shí)能夠在鏈路中一直傳遞下去呢？如果在請(qǐng)求源頭染色，那么請(qǐng)求經(jīng)過(guò)網(wǎng)關(guān)時(shí)，網(wǎng)關(guān)作為代理會(huì)將請(qǐng)求原封不動(dòng)的轉(zhuǎn)發(fā)給入口服務(wù)，除非開(kāi)發(fā)者在網(wǎng)關(guān)的路由策略中實(shí)施請(qǐng)求內(nèi)容修改策略。接著，請(qǐng)求流量會(huì)從入口服務(wù)開(kāi)始調(diào)用下一個(gè)微服務(wù)，會(huì)根據(jù)業(yè)務(wù)代碼邏輯形成新的調(diào)用請(qǐng)求，那么我們?nèi)绾螌⒒叶葮?biāo)識(shí)添加到這個(gè)新的調(diào)用請(qǐng)求，從而可以在鏈路中傳遞下去呢？
從單體架構(gòu)演進(jìn)到分布式微服務(wù)架構(gòu)，服務(wù)之間調(diào)用從同一個(gè)線程中方法調(diào)用變?yōu)閺谋镜剡M(jìn)程的服務(wù)調(diào)用遠(yuǎn)端進(jìn)程中服務(wù)，并且遠(yuǎn)端服務(wù)可能以多副本形式部署，以至于一條請(qǐng)求流經(jīng)的節(jié)點(diǎn)是不可預(yù)知的、不確定的，而且其中每一跳的調(diào)用都有可能因?yàn)榫W(wǎng)絡(luò)故障或服務(wù)故障而出錯(cuò)。分布式鏈路追蹤技術(shù)對(duì)大型分布式系統(tǒng)中請(qǐng)求調(diào)用鏈路進(jìn)行詳細(xì)記錄，核心思想就是通過(guò)一個(gè)全局唯一的 traceid 和每一條的 spanid 來(lái)記錄請(qǐng)求鏈路所經(jīng)過(guò)的節(jié)點(diǎn)以及請(qǐng)求耗時(shí)，其中 traceid 是需要整個(gè)鏈路傳遞的。

借助于分布式鏈路追蹤思想，我們也可以傳遞一些自定義信息，比如灰度標(biāo)識(shí)。業(yè)界常見(jiàn)的分布式鏈路追蹤產(chǎn)品都支持鏈路傳遞用戶自定義的數(shù)據(jù)，其數(shù)據(jù)處理流程如下圖所示：

邏輯環(huán)境隔離——基于 SDK

上面我們?cè)敿?xì)介紹了實(shí)現(xiàn)全鏈路灰度所需要的幾種技術(shù)，如果想為現(xiàn)有的業(yè)務(wù)接入全鏈路灰度能力，不可避免的需要為業(yè)務(wù)使用的開(kāi)發(fā)框架 SDK 進(jìn)行改造。首先，需要支持動(dòng)態(tài)路由功能，對(duì)于 Spring Cloud、Dubbo 開(kāi)發(fā)框架，可以對(duì)出口流量實(shí)現(xiàn)自定義 Filter，在該 Filter 中完成流量識(shí)別以及標(biāo)簽路由。同時(shí)需要借助分布式鏈路追蹤技術(shù)完成流量標(biāo)識(shí)鏈路傳遞以及流量自動(dòng)染色。此外，需要引入一個(gè)中心化的流量治理平臺(tái)，方便各個(gè)業(yè)務(wù)線的開(kāi)發(fā)者定義自己的全鏈路灰度規(guī)則?；?SDK 實(shí)現(xiàn)方式的圖例如下：

邏輯環(huán)境隔離——基于 Java Agent

基于 SDK 方式的弊端在于需要業(yè)務(wù)進(jìn)行 SDK 版本升級(jí)，甚至?xí)婕暗綐I(yè)務(wù)代碼的變動(dòng)。企業(yè)內(nèi)部各個(gè)微服務(wù)雖然使用同一種開(kāi)發(fā)框架，但很難保證框架版本是一致的，所以不得不為每一個(gè)版本維護(hù)一份全鏈路灰度的代碼。業(yè)務(wù)代碼與 SDK 代碼緊耦合，SDK 版本迭代會(huì)觸發(fā)業(yè)務(wù)不必要的發(fā)版變更，對(duì)業(yè)務(wù)的侵入性比較強(qiáng)。

另一種比較流行的方式是基于字節(jié)碼增強(qiáng)技術(shù)在編譯時(shí)對(duì)開(kāi)發(fā)框架進(jìn)行功能拓展，這種方案業(yè)務(wù)無(wú)感知，以無(wú)侵入方式為業(yè)務(wù)引入全鏈路灰度能力。基于 Java Agent 的實(shí)現(xiàn)方式的圖例如下：

但仍然無(wú)法避免是開(kāi)發(fā)者需要為業(yè)務(wù)使用版本不一致的開(kāi)發(fā)框架維護(hù)對(duì)應(yīng)的 Java Agent 的版本。如果您比較傾向于這種無(wú)侵入的方案但又不想自己來(lái)維護(hù)，您可以選擇阿里云 MSE 服務(wù)治理產(chǎn)品，該產(chǎn)品就是一款基于 Java Agent 實(shí)現(xiàn)的無(wú)侵入式企業(yè)生產(chǎn)級(jí)服務(wù)治理產(chǎn)品，您不需要修改任何一行業(yè)務(wù)代碼，即可擁有不限于全鏈路灰度的治理能力，并且支持近 5 年內(nèi)所有的 Spring Boot、Spring Cloud 和 Dubbo。

邏輯環(huán)境隔離——基于 Service Mesh

在業(yè)務(wù)系統(tǒng)的微服務(wù)架構(gòu)中，如果存在大量使用不同的技術(shù)棧、語(yǔ)言棧的微服務(wù)，Java Agent 的方式就無(wú)能為力了。我們可能需要為每一個(gè)語(yǔ)言的 SDK 編寫(xiě)和維護(hù)全鏈路灰度代碼，不僅需要不同語(yǔ)言棧的開(kāi)發(fā)者，而且涉及到語(yǔ)言無(wú)關(guān)的 bug 修復(fù)時(shí)需要全語(yǔ)言版本的 SDK 共同升級(jí)，這種代價(jià)不見(jiàn)得比基于物理環(huán)境隔離方案小。

那有沒(méi)有一種與語(yǔ)言無(wú)關(guān)的方案呢？有，下一代微服務(wù)架構(gòu)服務(wù)網(wǎng)格，Service Mesh。它將分布式服務(wù)的通信層抽象為單獨(dú)的一層，在這一層中實(shí)現(xiàn)負(fù)載均衡、服務(wù)發(fā)現(xiàn)、認(rèn)證授權(quán)、監(jiān)控追蹤、流量控制等分布式系統(tǒng)所需要的功能。顯然，我們所需的全鏈路灰度能力也可以在這個(gè)流量治理基礎(chǔ)設(shè)施層來(lái)實(shí)現(xiàn)。幸運(yùn)的是，服務(wù)網(wǎng)格明星產(chǎn)品Istio以聲明式 API 資源對(duì)流量治理進(jìn)行了統(tǒng)一抽象，借助于 VirtualService 和 DestinationRule 治理規(guī)則可以很容易實(shí)現(xiàn)全鏈路灰度的效果，并且Istio集成了各種主流的分布式鏈路追蹤框架。基于 Service Mesh 的實(shí)現(xiàn)方式的圖例如下：

在實(shí)際生產(chǎn)環(huán)境中，服務(wù)多版本并行開(kāi)發(fā)是很常見(jiàn)的事情，而且版本迭代速度非?？?。版本每次變更都需要修改 VirtualSerivice 資源中路由匹配規(guī)則，另外 VirtualSerivice 資源中并沒(méi)有提供容災(zāi)能力。比如存在一條路由規(guī)則訪問(wèn)服務(wù)提供方的某個(gè)灰度版本，如果目標(biāo)服務(wù)不存在該灰度版本或者不可用，按照目前 Istio 的實(shí)現(xiàn)是仍然將流量轉(zhuǎn)發(fā)至該版本，缺乏容災(zāi)機(jī)制。還有一種業(yè)務(wù)場(chǎng)景，如果我們希望對(duì)處于一定 UID 范圍的用戶流量轉(zhuǎn)發(fā)指定灰度環(huán)境，是無(wú)法通過(guò) Istio 現(xiàn)有的流量治理規(guī)則實(shí)現(xiàn)的。此時(shí)，您可以選擇阿里云服務(wù)網(wǎng)格產(chǎn)品 ASM，是一個(gè)統(tǒng)一管理微服務(wù)應(yīng)用流量、兼容 Istio 的托管式平臺(tái)。ASM 針對(duì)上述兩個(gè)場(chǎng)景都有應(yīng)對(duì)方案，輕松解決您在多語(yǔ)言場(chǎng)景下的全鏈路灰度訴求。

三種方式對(duì)比

下表是三種方式對(duì)比，從多個(gè)方面進(jìn)行了對(duì)比。

• 
  如果您傾向于使用無(wú)侵入式的 Java Agent 的方式，但又擔(dān)心自建帶來(lái)的穩(wěn)定性問(wèn)題，您可以選擇 MSE 微服務(wù)治理產(chǎn)品，該產(chǎn)品是阿里巴巴內(nèi)部多年在微服務(wù)治理領(lǐng)域的沉淀的產(chǎn)出，經(jīng)歷了各種大促考驗(yàn)。

• 如果您傾向于使用語(yǔ)言無(wú)關(guān)、無(wú)侵入式的 Service Mesh 的方式，但又擔(dān)心自建帶來(lái)的穩(wěn)定性問(wèn)題，您可以選擇阿里云 ASM 產(chǎn)品，相比開(kāi)源 Istio，在功能性、穩(wěn)定性和安全性都有很大的提升。

3
 流量入口：網(wǎng)關(guān)


在分布式應(yīng)用中，作為流量入口的網(wǎng)關(guān)是不可或缺的。在全鏈路灰度場(chǎng)景中，就要求微服務(wù)網(wǎng)關(guān)具備豐富的流量治理能力，支持服務(wù)多版本路由，支持對(duì)特定路由規(guī)則上的請(qǐng)求進(jìn)行動(dòng)態(tài)打標(biāo)。對(duì)于入口服務(wù)可見(jiàn)性問(wèn)題，網(wǎng)關(guān)需要支持多種服務(wù)發(fā)現(xiàn)方式。安全性問(wèn)題上，網(wǎng)關(guān)作為集群對(duì)外的入口可以對(duì)所有請(qǐng)求流量進(jìn)行認(rèn)證鑒權(quán)，保障業(yè)務(wù)系統(tǒng)不被非法流量入侵。

在虛擬化時(shí)期的微服務(wù)架構(gòu)下，業(yè)務(wù)通常采用流量網(wǎng)關(guān) + 微服務(wù)網(wǎng)關(guān)的兩層架構(gòu)，流量網(wǎng)關(guān)負(fù)責(zé)南北向流量調(diào)度和安全防護(hù)，微服務(wù)網(wǎng)關(guān)負(fù)責(zé)東西向流量調(diào)度和服務(wù)治理。在容器和 K8s 主導(dǎo)的云原生時(shí)代，Ingress 成為 K8s 生態(tài)的網(wǎng)關(guān)標(biāo)準(zhǔn)，賦予了網(wǎng)關(guān)新的使命，使得流量網(wǎng)關(guān) + 微服務(wù)網(wǎng)關(guān)合二為一成為可能。阿里云 MSE 發(fā)布的云原生網(wǎng)關(guān)在能力不打折的情況下，將兩層網(wǎng)關(guān)變?yōu)橐粚?，不僅可以節(jié)省 50% 的資源成本，還可以降低運(yùn)維及使用成本。最重要的是，云原生網(wǎng)關(guān)支持與后端微服務(wù)治理聯(lián)動(dòng)實(shí)現(xiàn)端到端的全鏈路灰度。