在我們項目進行版本升級的時候，肯定要求系統不間斷的提供服務，如果直接將某版本上線發布給全部用戶，一旦遇到線上事故（或BUG），對用戶的影響極大，解決問題周期較長，甚至有時不得不回滾到前一版本，嚴重影響了用戶體驗。
基于此，可以采用灰度發布的方式來解決。

單體架構下的服務發布

?先，我們先看?下在單體架構中，如何對應?中某個服務模塊進?新版本發布。如下圖，應用中的Cart服務模塊有新版本迭代：

由于 Cat 服務是應用的一部分，所以新版本上線時需要對整個應用進行編譯、打包以及部署服務級別發布問題變成了應用級別的發布問題，我們需要對應用的新版本而不是服務來實施有效的發布策略。

目前業界已經有非常成熟的服務發布方案，例如藍綠發布和灰度發布。

藍綠發布

藍綠發布需要對服務的新版本進?冗余部署，?般新版本的機器規格和數量與舊版本保持?致，相當于該服務有兩 套完全相同的部署環境，只不過此時只有舊版本在對外提供服務，新版本作為熱備。當服務進 ?版本升級時，我們只需將流量全部切換到新版本即可，舊版本作為熱備。我們的例?使?藍 綠發布的示意圖如下，流量切換基于四層代理的流量?關即可完成。

在藍綠發布中，由于存在流量整體切換，所以需要按照原服務占用的機器規模為新版本克隆一套環境，相當于要求原來一倍的機器資源。

灰度發布

根據請求內容或者請求流量的比例將線上流量的一小部分轉發至新版本，待灰度驗證通過后，逐步調大新版本的請求流量，是一種循序漸進的發布方式。 我們的例?使?灰度發布的示意圖如下，基于內容或?例的流量控制需要借助于?個七層代理的微服務?關來完成。

• Traffic Routing,基于內容的灰度方式，比如在請求頭上攜帶tag=gray的流量路由到v2版本；
• Traffic Shifting,基于比例的灰度方式，以無差別的方式對線上流量按照比重的方式進行分流

注意：灰度發布在機器資源成本以及流量控制能力更勝一籌，缺點就是發布周期過長，對運維基礎設施要求過高。

微服務架構下的服務發布

在分布式微服務架構中，應?中被拆分出來的?服務都是獨?部署、運?和迭代的。單個服務 新版本上線時，我們再也不需要對應?整體進?發版，只需關注每個微服務?身的發布流程即可，如下：

為了驗證服務Cart的新版本，流量在整個調用鏈路上能夠通過某種方式有選擇的路由到Cart的灰度版本。這屬于微服務治理領域中流量治理問題。

常見的治理策略包括基于Provide和基于Consumer的方式。

• 1、基于Provider的治理策略：配置Cart的流量流入規則，User路由到Cart時使用Cart的流量流入規則。
• 2、基于Consumer的治理策略：配置User的流量流出規則，User路由到Cart時使用User的流量流出規則。

全鏈路灰度發布

繼續考慮上面微服務體系中對服務Cart進行發布的場景，如果此時服務Order也需要發布新版本，由于本次新功能涉及到服務Cart和Order的共同變動，所以要求灰度驗證時能夠使得灰度流量同時經過服務Cart和Order的灰度版本。如下圖：

按照上一小節提出的兩種治理策略，我們需要額外配置服務 Order 的治理規則，確保來自灰度環境的服務 Cat 的流量轉發至服務 Order 的灰度版本。這樣的做法看似符合正常的操作邏輯但在真實業務場景中，業務的微服務規模和數量遠超我們的例子，其中一條請求鏈路可能經過數十個微服務，新功能發布時也可能會涉及到多個微服務同時變更，并且業務的服務之間依賴錯綜復雜，頻繁的服務發布、以及服務多版本并行開發導致流量治理規則日益膨脹，給整個系統的維護性和穩定性帶來了不利因素。

開發者結合實際業務場景和?產實踐經驗，提出了?種端到端的灰度發布?案，即全鏈路灰度。全鏈路灰度治理策略主要專注于整個調用鏈，它不關?鏈路上經過具體哪些微服務，流量控制視角從服務轉移至請求鏈路上，僅需要少量的治理規則即可構建出從網關到整個后端服務的多個流量隔離環境，有效保證了多個親密關系的服務順利安全發布以及服務多版本并行開發，進?步促進業務的快速發展。

如何在實際業務場景中去快速落地全鏈路灰度呢？
目前主要有兩種解決思路，基于物理環境隔離和基于邏輯環境隔離。

物理環境隔離

物理環境隔離，顧名思義，通過增加機器的方式來搭建真正意義上的流量隔離。

這種方案需要為要灰度的服務搭建一套網絡隔離、資源獨立的環境，在其中部署服務的灰度版本。由于與正式環境隔離，正式環境中的其他服務無法訪問到需要灰度的服務，所以需要在灰度環境中幾余部署這些線上服務，以便整個調用鏈路正常進行流量轉發。此外，注冊中心等-些其他依賴的中間件組件也 需要幾余部署在灰度環境中，保證微服務之間的可見性問題，確保獲取的節點 IP 地址只屬于當前的網絡環境。

邏輯環境隔離

我們只需部署服務的灰度版本，流量在調?鏈路上流轉時，由流經的?關、各個中間件以及各個微服務來識別灰度流量，并動態轉發?對應服務的灰度版本。如下圖：

上圖可以很好展示這種方案的效果，我們用不同的顏色來表示不同版本的灰度流量，可以看出無論是微服務網關還是微服務本身都需要識別流量，根據治理規則做出動態決策。

當服務版本發生變化時，這個調用鏈路的轉發也會實時改變。相比于利用機器搭建的灰度環境，這種方案 不僅可以節省大量的機器成本和運維人力，而且可以幫助開發者實時快速的對線上流量進行精細化的全鏈路控制。

那么全鏈路灰度具體是如何實現呢？通過上?的討論，我們需要解決以下問題：

• 1.鏈路上各個組件和服務能夠根據請求流量特征進?動態路由。
• 2.需要對服務下的所有節點進?分組，能夠區分版本。
• 3.需要對流量進?灰度標識、版本標識。
• 4.需要識別出不同版本的灰度流量

需要的技術：

標簽路由：標簽路由通過對服務下所有節點按照標簽名和標簽值不同進行分組，使得訂閱該服務節點信息的服務消費端可以按需訪問該服務的某個分組，即所有節點的一個子集。服務消費端可以使用服務提供者節點上的任何標簽信息，根據所選標簽的實際含義，消費端可以將標簽路由應用到更多的業務場景中。

流量染色：請求鏈路上各個組件如何識別出不同的灰度流量？流量染色，為請求流量添加不同灰度標識來方便區分。我們可以在請求的源頭上對流量進行染色，前端在發起請求時根據用戶信息或者平臺信息的不同對流量進行打標。如果前端無法做到，我們也可以在微服務網關上對匹配特定路由規則的請求動態添加流量標識。此外，流量在鏈路中流經灰度節點時，如果請求信息中不含有灰度標識，需要自動為其染色，接下來流量就可以在后續的流轉過程中優先訪問服務的灰度版本。

分布式鏈路追蹤：保證灰度標識能夠在鏈路中一直傳遞下去，分布式鏈路追蹤技術對大型分布式系統中請求調用鏈路進行詳細記錄，核心思想就是通過一個全局唯一的 traceid 和每一條的 spanid 來記錄請求鏈路所經過的節點以及請求耗時，其中traceid 是需要整個鏈路傳遞的。借助于分布式鏈路追蹤思想，我們也可以傳遞一些自定義信息，如灰度標識。業界常用的分布式鏈路追蹤產品都支持鏈路傳遞用戶自定義的數據。

首先，需要支持動態路由功能，對于 Spring Cloud、Dubbo 開發框架，可以對出口流量實現自定義 Filter，在該 Filter 中完成流量識別以及標簽路由。同時需要借助分布式鏈路追蹤技術完成流量標識鏈路傳遞以及流量自動染色。此外，需要引入一個中心化的流量治理平臺，方便各個業務線的開發者定義自己的全鏈路灰度規則。如下圖所示:

總結

以上是生活随笔為你收集整理的灰度发布整体解决方案的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。