當服務有新版本要發(fā)布上線時，通過引流一小部分流量到新版本，可以及時發(fā)現程序問題，有效阻止大面積故障的發(fā)生。業(yè)界上已經有比較成熟的服務發(fā)布策略，比如藍綠發(fā)布、A/B 測試以及金絲雀發(fā)布，這些發(fā)布策略主要專注于如何對單個服務進行發(fā)布。在微服務體系架構中，服務之間的依賴關系錯綜復雜，有時某個功能發(fā)版依賴多個服務同時升級上線。我們希望可以對這些服務的新版本同時進行小流量灰度驗證，這就是微服務架構中特有的全鏈路灰度場景，通過構建從網關到整個后端服務的環(huán)境隔離來對多個不同版本的服務進行灰度驗證。

本文將會揭開全鏈路灰度的神秘面紗，深入剖析全鏈路灰度技術內幕，引出兩種不同的實現方案，并對實現方案的技術細節(jié)進行深入探討，最后通過實踐環(huán)節(jié)來展示全鏈路灰度在實際業(yè)務中的使用場景。

01

微服務架構帶來的挑戰(zhàn)

Cloud Native

其中，流量網關是四層代理，主要功能有負載均衡、TLS 卸載以及一些安全防護功能；微服務網關是七層代理，主要用來暴露后端服務、流量治理、訪問控制和流量監(jiān)控。以"高內聚、低耦合"作為設計理念的微服務架構為開發(fā)者帶來了前所未有的開發(fā)體驗，每個業(yè)務團隊專注于自身業(yè)務的代碼邏輯，并通過 API 形式對外發(fā)布。服務依賴方只需引入服務提供方的 API 定義，即可完成服務之間通信，無需關心服務提供方的部署形態(tài)和內部實現。
但任何架構都不是銀彈，在解決舊問題同時勢必會引入一些新的問題。微服務體系中最令人頭疼的問題，是如何對眾多微服務進行高效、便捷的治理，主要表現在可見性、連接性和安全性這三個方面。進一步細化，微服務架構帶來了以下的挑戰(zhàn)：

本文的重點主要關注服務發(fā)布這一子領域，如何保證微服務體系中服務新版本升級過程中平滑無損，以及如何低成本的為多個微服務構建流量隔離環(huán)境，方便開發(fā)者同時對多個服務新版本進行充分的灰度驗證，避免故障的發(fā)生。
02

什么是全鏈路灰度

Cloud Native

1
單體架構下的服務發(fā)布

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

 

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

目前，業(yè)界已經有非常成熟的服務發(fā)布方案，例如藍綠發(fā)布和灰度發(fā)布。藍綠發(fā)布需要對服務的新版本進行冗余部署，一般新版本的機器規(guī)格和數量與舊版本保持一致，相當于該服務有兩套完全相同的部署環(huán)境，只不過此時只有舊版本在對外提供服務，新版本作為熱備。當服務進行版本升級時，我們只需將流量全部切換到新版本即可，舊版本作為熱備。我們的例子使用藍綠發(fā)布的示意圖如下，流量切換基于四層代理的流量網關即可完成。

 

在藍綠發(fā)布中，由于存在流量整體切換，所以需要按照原服務占用的機器規(guī)模為新版本克隆一套環(huán)境，相當于要求原來1倍的機器資源?；叶劝l(fā)布的核心思想是根據請求內容或者請求流量的比例將線上流量的一小部分轉發(fā)至新版本，待灰度驗證通過后，逐步調大新版本的請求流量，是一種循序漸進的發(fā)布方式。我們的例子使用灰度發(fā)布的示意圖如下，基于內容或比例的流量控制需要借助于一個七層代理的微服務網關來完成。

其中，Traffic Routing 是基于內容的灰度方式，比如請求中含有頭部 stag=gray 的流量路由到應用 v2 版本；Traffic Shifting 是基于比例的灰度方式，以無差別的方式對線上流量按比重進行分流。相比藍綠發(fā)布，灰度發(fā)布在機器資源成本以及流量控制能力上更勝一籌，但缺點就是發(fā)布周期過長，對運維基礎設施要求較高。
2
 微服務架構下的服務發(fā)布

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

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

• 基于 Provider 的治理策略。配置 Cart 的流量流入規(guī)則，User 路由到 Cart 時使用 Cart 的流量流入規(guī)則。

• 基于 Consumer 的治理策略。配置 User 的流量流出規(guī)則， User 路由到 Cart 時使用 User 的流量流出規(guī)則。

此外，使用這些治理策略時可以結合上面介紹的藍綠發(fā)布和灰度發(fā)布方案來實施真正的服務級別的版本發(fā)布。

3
 全鏈路灰度

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

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

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