日日操夜夜添-日日操影院-日日草夜夜操-日日干干-精品一区二区三区波多野结衣-精品一区二区三区高清免费不卡

概述

在互聯網公司中，產品通常迭代比較頻繁的，尤其涉及到一些關鍵比較大項目需求時，影響范圍比較大的時候，通常需要進行灰度控制，通過引流一小部分流量到新版本，可以及時發現程序問題，有效阻止大面積故障的發生。

業界上已經有比較成熟的服務發布策略，比如藍綠發布、A/B 測試以及金絲雀發布、滾動發布，這些發布策略主要專注于如何對單個服務進行發布。在微服務體系架構中，服務之間的依賴關系錯綜復雜，有時某個功能發版依賴多個服務同時升級上線。我們希望可以對這些服務的新版本同時進行小流量灰度驗證，這就是微服務架構中特有的全鏈路灰度場景，通過構建從網關到整個后端服務的環境隔離來對多個不同版本的服務進行灰度驗證。

灰度發布類型

灰度發布如果按照端來分的話，可以分為web前端、客戶端、服務端灰度。

無論是哪種灰度，一般需要滿足以下2點要求：

 

• 需要一個放量配置，給產品/運營等工作人員配置放量策略；
• 需要做到同一個用戶始終訪問的是同一個版本的代碼，如果同個用戶上個請求訪問的是A版本，下個請求訪問的是B版本，就可能會出問題。

web前端灰度

 

作為用戶體驗的入口，web前端的灰度是比較常用的方案。我們前端每次發布一個新版本，就把資源增量式地上傳到CDN，然后給它分配一個唯一的版本號，再把所有的版本號存儲起來。當處理請求時，根據動態配置的分流策略來決定用戶使用哪個版本。

比如分流策略是放量10%，即新版本隨機放量給10%的用戶使用，當用戶首次命中資源版本號時，需要把用戶id和版本號的映射關系存儲起來（可存到cookie），這樣就能保證同個用戶上次請求和下次請求訪問到的都是同個版本的代碼。

那如果線上有緊急bug需要修復，又要重新發布新版本，該如何處理當前灰度的狀態？是趕緊結束上一個灰度然后全量發布還是一起發上去同時灰度？一般來說，再有新版本發布或者放量策略發生變化時，應該重新分流灰度。

客戶端灰度

大家在使用App的時候，通常收到一些提示"是否體驗升級新版本"，通常收到該提示，說明你被系統劃分為灰度用戶。通常來講web前端灰度是在客戶無感知的情況下平滑進行，而APP灰度需要涉及到用戶的主動安裝行為。

客戶端在啟動時，會向灰度系統發起請求，灰度系統根據客戶端傳過來的參數和當前的放量策略來決定是否要給客戶端升級提醒。一般會根據以下幾種策略來決定給予用戶升級提醒：

 

1. 根據用戶設備的系統和應用版本；
2. 根據渠道：發布到不同應用市場的app都會被打上渠道標簽，所以可以根據渠道來區分用戶；
3. 根據設備ID和用戶ID。
4.  

 

通過設備ID主要是為了控制提醒頻率，用戶ID主要是為了區分出特性用戶，比如對活躍用戶發送提醒。

如果一個帶有bug的安裝包全量發布出去，一旦有問題，我們只能快速定位問題來提醒用戶安裝新版本，是否安裝取決于用戶，所以客戶端灰度發布是非常有必要的。

服務端灰度

服務端灰度分為兼容變更灰度和不兼容變更灰度。

1）兼容變更

兼容變更又可分為物理灰度和邏輯灰度。

 

• 物理灰度：物理灰度比較簡單，根據機器維度進行灰度，直接部署新老版本在不同機器，流量均勻地打在新老版本上面。這種方式雖然簡單，但不適用于不兼容變更；
• 邏輯灰度：邏輯灰度就是根據更精確的流量策略來控制流量，這種灰度一般要寫一定的灰度代碼。這種方式能比較精確地控制流量，但是增加了一定的灰度代碼，灰度完成后要刪除相關灰度代碼，有點麻煩。

 

2）不兼容變更

不兼容變更指的是更改了當前功能，即接口邏輯跟之前版本發生很大變化，必須要前后端同時發布，否則會有一段時間服務不可用。

一般的做法是引入接口版本號，新老版本接口并存，比如 /v1/api 和 /v2/api。前端使用/v2/api版本，當過去一段穩定期后（可以是登錄態時間失效后），就可下掉/v1/api版本。

灰度放量策略

流量策略一般分為以下幾種：

1. 按流量百分比

先到先得的方式比如限制10%的用戶體驗的是新版本，90%的用戶體驗的是老版本。先訪問網站的用戶就優先命中新版本，直到流量用完為止。

2. 按人群劃分

1）按用戶id、用戶ip、設備類型比如可通過平時的埋點上報數據得知用戶的pv、uv、頁面平均訪問時長等數據，根據用戶活躍度來讓用戶優先體驗新版本，進而快速觀察使用效果。

2）按地域、性別、年齡等用戶畫像比如可通過用戶的性別、年齡等做下新老版本的對比效果來看看目標用戶在新版本的使用年齡段，性別范圍是多少。

3. 按渠道劃分

比如根據用戶的注冊來源來放量。

灰度發布策略

灰度部署發布通常會分為三大類，主要包括藍綠發布、滾動發布、灰度發布，這三大類

藍綠發布

藍綠部署中，一共有兩套系統：一套是正在提供服務系統（也就是上面說的舊版），標記為“綠色”；另一套是準備發布的系統，標記為“藍色”。兩套系統都是功能完善的，并且正在運行的系統，只是系統版本和對外服務情況不同。正在對外提供服務的老系統是綠色系統，新部署的系統是藍色系統。

 

藍綠發布示意圖

藍色系統不對外提供服務，用來做啥？用來做發布前測試，測試過程中發現任何問題，可以直接在藍色系統上修改，不干擾用戶正在使用的系統。藍色系統經過反復的測試、修改、驗證，確定達到上線標準之后，直接將用戶切換到藍色系統，切換后的一段時間內，依舊是藍綠兩套系統并存，但是用戶訪問的已經是藍色系統。這段時間內觀察藍色系統（新系統）工作狀態，如果出現問題，直接切換回綠色系統。當確信對外提供服務的藍色系統工作正常，不對外提供服務的綠色系統已經不再需要的時候，藍色系統正式成為對外提供服務系統，成為新的綠色系統。原先的綠色系統可以銷毀，將資源釋放出來，用于部署下一個藍色系統。

藍綠發布特點

1. 藍綠部署的目的是減少發布時的中斷時間能夠快速撤回發布
2. 兩套系統沒有耦合的時候才能百分百保證不干擾

 

藍綠發布注意事項

藍綠部署只是上線策略中的一種，它不是可以應對所有情況的萬能方案。藍綠部署能夠簡單快捷實施的前提假設是目標系統是非常內聚的，如果目標系統相當復雜，那么如何切換、兩套系統的數據是否需要以及如何同步等，都需要仔細考慮。當你切換到藍色環境時，需要妥當處理未完成的業務和新的業務。如果你的數據庫后端無法處理，會是一個比較麻煩的問題：

 

• 可能會出現需要同時處理“微服務架構應用”和“傳統架構應用”的情況，如果在藍綠部署中協調不好這兩者，還是有可能會導致服務停止。
• 需要提前考慮數據庫與應用部署同步遷移/回滾的問題。
• 藍綠部署需要有基礎設施支持。
• 在非隔離基礎架構（VM 、 Docker等）上執行藍綠部署，藍色環境和綠色環境有被摧毀的風險。

滾動發布

 

一般是取出一個或者多個服務器停止服務，執行更新，并重新將其投入使用。周而復始，直到集群中所有的實例都更新成新版本。

 

滾動發布示意圖發布流程：

相對于藍綠發布需要一套完備的機器不同，滾動發布只需要一臺機器（這兒這是為了理解，實際可能是多臺），我們只需要將部分功能部署在這臺機器上，然后去替換正在運行的機器，如上圖，將更新后的功能部署在Server1上，然后Server1去替換正在運行的Server，替換下來的物理機又可以繼續部署Server2的新版本，然后去替換正在工作的Server2，以此類推，直到替換完所有的服務器，至此，服務更新完成。

滾動發布特點

1. 這種部署方式相對于藍綠部署，更加節約資源——它不需要運行兩個集群、兩倍的實例數。我們可以部分部署，例如每次只取出集群的20%進行升級。
2. 回滾困難
3.  

滾動發布注意事項

1. 滾動發布沒有一個確定可行的環境。使用藍綠部署，我們能夠清晰地知道老版本是可行的，而使用滾動發布，我們無法確定。
2. 修改了現有的環境。
3. 回滾困難。舉個例子，在某一次發布中，我們需要更新100個實例，每次更新10個實例，每次部署需要5分鐘。當滾動發布到第80個實例時，發現了問題，需要回滾，這個回滾卻是一個痛苦，并且漫長的過程。
4. 有的時候，我們還可能對系統進行動態伸縮，如果部署期間，系統自動擴容/縮容了，我們還需判斷到底哪個節點使用的是哪個代碼。盡管有一些自動化的運維工具，但是依然令人心驚膽戰。
5. 因為是逐步更新，那么我們在上線代碼的時候，就會短暫出現新老版本不一致的情況，如果對上線要求較高的場景，那么就需要考慮如何做好兼容的問題。

灰度發布

 

灰度發布，也叫金絲雀發布。是指在黑與白之間，能夠平滑過渡的一種發布方式。AB test就是一種灰度發布方式，讓一部分用戶繼續用A，一部分用戶開始用B，如果用戶對B沒有什么反對意見，那么逐步擴大范圍，把所有用戶都遷移到B上面來。灰度發布可以保證整體系統的穩定，在初始灰度的時候就可以發現、調整問題，以保證其影響度，而我們平常所說的金絲雀部署也就是灰度發布的一種方式。具體到服務器上, 實際操作中還可以做更多控制，譬如說，給最初更新的10臺服務器設置較低的權重、控制發送給這10臺服務器的請求數，然后逐漸提高權重、增加請求數。一種平滑過渡的思路, 這個控制叫做“流量切分”。

17世紀，英國礦井工人發現，金絲雀對瓦斯這種氣體十分敏感。空氣中哪怕有極其微量的瓦斯，金絲雀也會停止歌唱；而當瓦斯含量超過一定限度時，雖然魯鈍的人類毫無察覺，金絲雀卻早已毒發身亡。當時在采礦設備相對簡陋的條件下，工人們每次下井都會帶上一只金絲雀作為“瓦斯檢測指標”，以便在危險狀況下緊急撤離。

 

灰度發布示意圖過程：

 

1. 準備好部署各個階段的工件，包括：構建工件，測試腳本，配置文件和部署清單文件。
2. 將“金絲雀”服務器部署進服務器中，測試。
3. 從負載均衡列表中移除掉“金絲雀”服務器。
4. 升級“金絲雀”應用（排掉原有流量并進行部署）。
5. 對應用進行自動化測試。
6. 將“金絲雀”服務器重新添加到負載均衡列表中（連通性和健康檢查）。
7. 如果“金絲雀”在線使用測試成功，升級剩余的其他服務器。（否則就回滾）

A/B測試

 

A/B測試和藍綠發布、滾動發布以及金絲雀發布，完全是兩回事。

藍綠發布、滾動發布和金絲雀是發布策略，目標是確保新上線的系統穩定，關注的是新系統的BUG、隱患。

A/B測試是效果測試，同一時間有多個版本的服務對外服務，這些服務都是經過足夠測試，達到了上線標準的服務，有差異但是沒有新舊之分（它們上線時可能采用了藍綠部署的方式）。

A/B測試關注的是不同版本的服務的實際效果，譬如說轉化率、訂單情況等。

A/B測試時，線上同時運行多個版本的服務，這些服務通常會有一些體驗上的差異，譬如說頁面樣式、顏色、操作流程不同。相關人員通過分析各個版本服務的實際效果，選出效果最好的版本。

 

小結

綜上所述，三種方式均可以做到平滑式升級，在升級過程中服務仍然保持服務的連續性，升級對外界是無感知的。那生產上選擇哪種部署方法最合適呢？這取決于哪種方法最適合你的業務和技術需求。如果你們運維自動化能力儲備不夠，肯定是越簡單越好，建議藍綠發布，如果業務對用戶依賴很強，建議灰度發布。如果是K8S平臺，滾動更新是現成的方案，建議先直接使用。

 

• 藍綠發布：兩套環境交替升級，舊版本保留一定時間便于回滾。
• 灰度發布：根據比例將老版本升級，例如80%用戶訪問是老版本，20%用戶訪問是新版本。
• 滾動發布：按批次停止老版本實例，啟動新版本實例。

全鏈路灰度設計方案

 

為了滿足業務的迭代速度，開發者開始對原來的單體架構進行細粒度的拆分，將單體應用中的服務模塊拆分成一個個獨立部署運行的微服務，并且這些微服務的生命周期由對應的業務團隊獨自負責，有效的解決了單體架構中存在的敏捷性不足、靈活性不強的問題。

但任何架構都不是銀彈，在解決舊問題同時勢必會引入一些新的問題。微服務體系中最令人頭疼的問題，是如何對眾多微服務進行高效、便捷的治理，主要表現在可見性、連接性和安全性這三個方面。

如何保證微服務體系中服務新版本升級過程中平滑無損，以及如何低成本的為多個微服務構建流量隔離環境，方便開發者同時對多個服務新版本進行充分的灰度驗證，避免故障的發生，是本章節主要會涉及到的內容，以下內容的討論主要以電商系統中的購物車、訂單為例進行說明。

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

 

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

 

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

 

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

全鏈路灰度

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

 

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

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

全鏈路灰度的解決方案

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

物理環境隔離

物理環境隔離，顧名思義，通過增加機器的方式來搭建真正意義上的流量隔離，物理隔離更多的屬于藍綠發布方案。

 

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

這個方案一般用于企業的測試、預發開發環境的搭建，對于線上灰度發布引流的場景來說其靈活性不夠。況且，微服務多版本的存在在微服務架構中是家常便飯，需要為這些業務場景采用堆機器的方式來維護多套灰度環境。如果您的應用數目過多的情況下，會造成運維、機器成本過大，成本和代價遠超收益；如果應用數目很小，就兩三個應用，這個方式還是很方便的，可以接受的。

邏輯環境隔離

另一種方案是構建邏輯上的環境隔離，我們只需部署服務的灰度版本，流量在調用鏈路上流轉時，由流經的網關、各個中間件以及各個微服務來識別灰度流量，并動態轉發至對應服務的灰度版本。如下圖：

 

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

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

 

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

 

接下來，會介紹解決上述問題需要用到的技術。

版本路由

無論是網關暴露的http接口還是dubbo接口，都會有相應的版本號，在進行灰度發布設計的時候可充分考慮前端、網關、后端dubbo服務版本號傳遞。

標簽路由

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

 

節點打標

那么如何給服務節點添加不同的標簽呢？在如今火熱的云原生技術推動下，大多數業務都在積極進行容器化改造之旅。這里，我就以容器化的應用為例，介紹在使用 Kube.NETes Service 作為服務發現和使用比較流行的 Nacos 注冊中心這兩種場景下如何對服務 Workload 進行節點打標。

在使用 Kubernetes Service 作為服務發現的業務系統中，服務提供者通過向 ApiServer 提交 Service 資源完成服務暴露，服務消費端監聽與該 Service 資源下關聯的 Endpoint 資源，從 Endpoint 資源中獲取關聯的業務 Pod 資源，讀取上面的 Labels 數據并作為該節點的元數據信息。所以，我們只要在業務應用描述資源 Deployment 中的 Pod 模板中為節點添加標簽即可。

 

在使用 Nacos 作為服務發現的業務系統中，一般是需要業務根據其使用的微服務框架來決定打標方式。如果 JAVA 應用使用的 Spring Cloud 微服務開發框架，我們可以為業務容器添加對應的環境變量來完成標簽的添加操作。比如我們希望為節點添加版本灰度標，那么為業務容器添加spring.cloud.nacos.discovery.metadata.version=gray，這樣框架向Nacos注冊該節點時會為其添加一個標簽verison=gray。

 

流量染色

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

邏輯環境隔離——基于 SDK

上面我們詳細介紹了實現全鏈路灰度所需要的幾種技術，如果想為現有的業務接入全鏈路灰度能力，不可避免的需要為業務使用的開發框架 SDK 進行改造。首先，需要支持動態路由功能，對于 Spring Cloud、Dubbo 開發框架，可以對出口流量實現自定義 Filter，在該 Filter 中完成流量識別以及標簽路由。同時需要借助分布式鏈路追蹤技術完成流量標識鏈路傳遞以及流量自動染色。此外，需要引入一個中心化的流量治理平臺，方便各個業務線的開發者定義自己的全鏈路灰度規則。基于 SDK 實現方式的圖例如下：

 

邏輯環境隔離——基于 Java Agent

基于 SDK 方式的弊端在于需要業務進行 SDK 版本升級，甚至會涉及到業務代碼的變動。企業內部各個微服務雖然使用同一種開發框架，但很難保證框架版本是一致的，所以不得不為每一個版本維護一份全鏈路灰度的代碼。業務代碼與 SDK 代碼緊耦合，SDK 版本迭代會觸發業務不必要的發版變更，對業務的侵入性比較強。

另一種比較流行的方式是基于字節碼增強技術在編譯時對開發框架進行功能拓展，這種方案業務無感知，以無侵入方式為業務引入全鏈路灰度能力。基于 Java Agent 的實現方式的圖例如下：

 

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

邏輯環境隔離——基于 Service Mesh

在業務系統的微服務架構中，如果存在大量使用不同的技術棧、語言棧的微服務，Java Agent 的方式就無能為力了。我們可能需要為每一個語言的 SDK 編寫和維護全鏈路灰度代碼，不僅需要不同語言棧的開發者，而且涉及到語言無關的 bug 修復時需要全語言版本的 SDK 共同升級，這種代價不見得比基于物理環境隔離方案小。

那有沒有一種與語言無關的方案呢？有，下一代微服務架構服務網格，Service Mesh。它將分布式服務的通信層抽象為單獨的一層，在這一層中實現負載均衡、服務發現、認證授權、監控追蹤、流量控制等分布式系統所需要的功能。顯然，我們所需的全鏈路灰度能力也可以在這個流量治理基礎設施層來實現。幸運的是，服務網格明星產品Istio以聲明式 API 資源對流量治理進行了統一抽象，借助于 VirtualService 和 DestinationRule 治理規則可以很容易實現全鏈路灰度的效果，并且Istio集成了各種主流的分布式鏈路追蹤框架。基于 Service Mesh 的實現方式的圖例如下：

 

在實際生產環境中，服務多版本并行開發是很常見的事情，而且版本迭代速度非常快。版本每次變更都需要修改 VirtualSerivice 資源中路由匹配規則，另外 VirtualSerivice 資源中并沒有提供容災能力。比如存在一條路由規則訪問服務提供方的某個灰度版本，如果目標服務不存在該灰度版本或者不可用，按照目前 Istio 的實現是仍然將流量轉發至該版本，缺乏容災機制。還有一種業務場景，如果我們希望對處于一定 UID 范圍的用戶流量轉發指定灰度環境，是無法通過 Istio 現有的流量治理規則實現的。此時，您可以選擇阿里云服務網格產品 ASM，是一個統一管理微服務應用流量、兼容 Istio 的托管式平臺。ASM 針對上述兩個場景都有應對方案，輕松解決您在多語言場景下的全鏈路灰度訴求。

三種方式對比

下表是三種方式對比，從多個方面進行了對比：

 

 

• 如果您傾向于使用無侵入式的 Java Agent 的方式，但又擔心自建帶來的穩定性問題，您可以選擇 MSE 微服務治理產品，該產品是阿里巴巴內部多年在微服務治理領域的沉淀的產出，經歷了各種大促考驗。
• 如果您傾向于使用語言無關、無侵入式的 Service Mesh 的方式，但又擔心自建帶來的穩定性問題，您可以選擇阿里云 ASM 產品，相比開源 Istio，在功能性、穩定性和安全性都有很大的提升。

流量入口：網關

 

在分布式應用中，作為流量入口的網關是不可或缺的。在全鏈路灰度場景中，就要求微服務網關具備豐富的流量治理能力，支持服務多版本路由，支持對特定路由規則上的請求進行動態打標。對于入口服務可見性問題，網關需要支持多種服務發現方式。安全性問題上，網關作為集群對外的入口可以對所有請求流量進行認證鑒權，保障業務系統不被非法流量入侵。

在虛擬化時期的微服務架構下，業務通常采用流量網關 + 微服務網關的兩層架構，流量網關負責南北向流量調度和安全防護，微服務網關負責東西向流量調度和服務治理。傳統的網關比如zuul、springcloud gateway以及Apache的shenyu網關都可以擴展在一定程度上支持灰度發布。

在容器和 K8s 主導的云原生時代，Ingress 成為 K8s 生態的網關標準，賦予了網關新的使命，使得流量網關 + 微服務網關合二為一成為可能。阿里云 MSE 發布的云原生網關在能力不打折的情況下，將兩層網關變為一層，不僅可以節省 50% 的資源成本，還可以降低運維及使用成本。最重要的是，云原生網關支持與后端微服務治理聯動實現端到端的全鏈路灰度。

 

灰度設計實踐

灰度發布的最終要解決的問題，基于一定的流量測試，測試沒有問題后會進行全量放開，具體如下圖：

 

具體實現思路如下：

 

1. 在代碼中做。

 

一套線上環境，代碼中做開關，對于不同的用戶走不同的邏輯

 

1. 在接入層做。

 

多套(隔離的)線上環境，接入層針對不同用戶轉發到不同的環境中

兩種方案的優缺點：

方案

優點

缺點

在代碼中做

靈活，粒度細；一套代碼(環境)運維成本低

灰度邏輯侵入代碼

在接入層做

無需（少）侵入代碼；風險小

多套線上環境，運維成本高

靈活的灰度方案一般需要在接入層實現，具體就是自定義負載均衡策略實現。

下面介紹在接入層使用的方式:

 

• Nginx層實現（使用nginx+lua）
• 網關層實現
• dubbo的灰度，項目中如果使用dubbo，有可能會需要dubbo服務的灰度實現。

 

負載均衡又可分為服務端負載均衡和客戶端負載均衡

服務器端負載均衡：例如Nginx，通過Nginx進行負載均衡，先發送請求，然后通過負載均衡算法，在多個服務器之間選擇一個進行訪問；即在服務器端再進行負載均衡算法分配。

客戶端負載均衡：例如ribbon或者dubbo，客戶端會有一個服務器地址列表，在發送請求前通過負載均衡算法選擇一個服務器，然后進行訪問，這是客戶端負載均衡；即在客戶端就進行負載均衡算法分配。

基于Nginx灰度發布方案

基于前端不同的用戶的cookie:tts_version_id的值不同進行灰度分流，具體nginx.conf配置如下圖：

 

如果用戶灰度分流的策略比較復雜，推薦兩個開源的項目Openresty、ABTestingGateway。

Openresty

OpenResty® 是一個基于 Nginx 與 Lua 的高性能 Web 平臺，其內部集成了大量精良的 Lua 庫、第三方模塊以及大多數的依賴項。用于方便地搭建能夠處理超高并發、擴展性極高的動態 Web 應用、Web 服務和動態網關。

Openresty學習地址：https://moonbingbing.gitbooks.io/openresty-best-practices/content/base/intro.html

ABTestingGateway

ABTestingGateway是新浪微博的開源的項目，是一個可以動態設置分流策略的灰度發布系統，工作在7層，基于nginx和ngx-lua開發，使用 redis 作為分流策略數據庫，可以實現動態調度功能。

ABTestingGateway是在 nginx 轉發的框架內，在轉向 upstream 前，根據 用戶請求特征 和 系統的分流策略 ，查找出目標upstream，進而實現分流。

nginx實現的灰度系統中，分流邏輯往往通過 rewrite 階段的 if 和rewrite 指令等實現，優點是性能較高，缺點是功能受限、容易出錯，以及轉發規則固定，只能靜態分流。針對這些缺點， ABTestingGateway，采用ngx-lua 實現系統功能，通過啟用lua-shared-dict和lua-resty-lock作為系統緩存和緩存鎖，系統獲得了較為接近原生nginx轉發的性能。

git地址：https://github.com/CNSRE/ABTestingGateway

基于dubbo灰度發布方案

dubbo在設計之初對灰度發布就提供了很好的支持，它現在支持兩種路由方式：條件路由、標簽路由。

條件路由主要支持以服務或Consumer應用為粒度配置路由規則，源碼對應的路由器是ConditionRouter.java。

標簽路由主要是以Provider應用為粒度配置路由規則，通過將某一個或多個服務的提供者劃分到同一個分組，約束流量只在指定分組中流轉，從而實現流量隔離的目的，對應源碼路由器是TagRouter.java。

Dubbo原生路由器支持的場景其實已經很豐富的了，比如條件路由器，可以設置排除預發布機器、指定Consumer應用訪問指定的Provider應用，這其實就是藍綠發布，還能設置黑白名單、按網段訪問等等，這些所有的標簽管理我們都可以再dubbo-admin進行管理。如果你的灰度分流策略過于復雜以至于上述兩個路由不滿足，我們可以自定義實現一個Router，基于Dubbo SPI的擴展成本非常低，我們只需定義自己的路由器并把整合到應用就可以了。

灰度路由器是以provider應用為粒度配置路由規則的，包含兩個過濾器，條件過濾器和權重過濾器（不是Dubbo的過濾器），它們的主要任務根據配置過濾出備用provoider。配置信息放在分布式配置上，首次加載放入應用緩存，一旦有變更將自動更新。這樣在發布時可以動態調整灰度參數，達到逐步擴大流量和影響人群的目的。

dubbo官方文檔，對于路由這塊的支持介紹的比較詳細，具體文檔可以參考：https://dubbo.apache.org/zh/docs3-v2/java-sdk/advanced-features-and-usage/service/routing/routing-rule/

基于SpringCloud灰度發布方案

Ribbon 提供了幾個負載均衡的組件，其目的就是讓請求轉給合適的服務器處理。

 

默認輪詢

自定義策略需要繼承AbstractLoadBalancerRule

開源方案：

自定義DiscoveryEnabledRule繼承PredicateBaseRule

 

首先在請求開始處，實現自己的灰度邏輯，比如下面的demo根據請求url如果包含‘version’向holder中添加route為A的標識，否則添加route為B的標識。 (Holder本質是一個localThread)

 

在目標服務添加matadateMap

 

PredicateBaseRule中使用google提供的pridicate，MetadataAwarePredicate中實現apply方法判斷發現的服務是否是目標服務

 

最后基于SpringCloud的灰度發布推薦如下兩個開源項目：

https://github.com/SpringCloud/spring-cloud-gray

https://github.com/Nepxion/Discovery

灰度發布devops工具平臺分布式鏈路追蹤

還有一個很重要的問題是如何保證灰度標識能夠在鏈路中一直傳遞下去呢？如果在請求源頭染色，那么請求經過網關時，網關作為代理會將請求原封不動的轉發給入口服務，除非開發者在網關的路由策略中實施請求內容修改策略。接著，請求流量會從入口服務開始調用下一個微服務，會根據業務代碼邏輯形成新的調用請求，那么我們如何將灰度標識添加到這個新的調用請求，從而可以在鏈路中傳遞下去呢？

從單體架構演進到分布式微服務架構，服務之間調用從同一個線程中方法調用變為從本地進程的服務調用遠端進程中服務，并且遠端服務可能以多副本形式部署，以至于一條請求流經的節點是不可預知的、不確定的，而且其中每一跳的調用都有可能因為網絡故障或服務故障而出錯。分布式鏈路追蹤技術對大型分布式系統中請求調用鏈路進行詳細記錄，核心思想就是通過一個全局唯一的 traceid 和每一條的 spanid 來記錄請求鏈路所經過的節點以及請求耗時，其中 traceid 是需要整個鏈路傳遞的。

借助于分布式鏈路追蹤思想，我們也可以傳遞一些自定義信息，比如灰度標識。業界常見的分布式鏈路追蹤產品都支持鏈路傳遞用戶自定義的數據，其數據處理流程如下圖所示：

 

其中可以使用SkyWalking作為全鏈路跟蹤中間件，能夠很好的根據traceId進行灰度鏈路跟蹤。

監控與告警

一個好的系統或產品，僅實現其基本功能是遠遠不夠的，可觀測、易運維也是必不可少的。主要包括發布應用監控、告警事件通知、全局發布狀態以及周期統計報表，這里強烈推薦Prometheus+Grafana作為云原生監控告警平臺。

灰度發布期間新老兩個集群運行兩個應用版本，需要能夠對新老集群的出、入流量的QPS、耗時、失敗率等指標進行監控，通過對比新舊兩個版本集群的實時監控數據，用戶可以快速的發現問題。如下圖所示：

 

文章最后推薦一下我的知識星球，知識星球可以和我探討一下技術與管理，歡迎大家加入。