自從用了灰度發佈，睡覺真香！

前言

大家好，我是棧長。

最近，棧長又參加了騰訊雲小伙伴邀請的Techo Day 技術開放日 2.0的線上活動，這一期又是乾貨滿滿，主要是雲原生和微服務方面的，比如：雲原生網關、容器、安全、雲監控、灰度發佈等等，這些內容都與我們現有的微服務系統息息相關。

令棧長印象最深刻的就是微服務灰度發佈這個主題，騰訊開源的北極星讓我大開眼界，不僅涵蓋微服務多個解決方案，還包括市面上少有的、開源的一站式灰度發佈解決方案。

看到這，大家心裡可能會有以下問題：

• 啥是灰度發佈，對咱們業務能帶來什麼好處？
• 我知道灰度發佈，但是灰度發佈實現方式那麼多，我該怎麼選？
• 北極星是啥，和我現在使用的灰度發佈框架有啥區別呢？

針對大家這些問題，所以我想有必要給大家做個專題分享，包括灰度發佈的基本認識、分類，特別是騰訊開源的北極星項目，看它是如何輕鬆解決灰度發佈的。

什麼是灰度發佈？

說到灰度發佈就不得不提 "全量發佈" ，全量發佈就是所有系統都同時上線新版本，即對所有用戶都同時使用新版本，這會帶來什麼問題？

全量發佈的種種弊端：

• 影響用戶體驗： 比如某系統在雙 11 前上線了一個新功能，需要給符合條件的用戶發放優惠券，結果程式出 bug 導致給所有用戶都發放了……又或者是新版本系統出現問題，從而影響所有用戶……
• 系統異常擴散風險： 比較某系統上線後不久出現了一個記憶體溢出的異常，流量接而轉移到了系統其他實例，從而導致該系統所有實例都記憶體溢出，所有實例都處於不可用狀態……
• 影響服務可用性： 全量發佈一般都需要全部停機升級，從而保證要麼是新版本，要麼是老版本，這顯然會導致業務中斷，也影響了服務可用性（SLA），就是我們經常看到互聯網公司喊口號，我們今年一定要做到 3 個 9、4 個 9，即 99.9%、99.99% 等等，SLA 就是衡量系統服務可用性的一個保證，9 越多代表全年服務可用時間越長服務更可靠，停機時間越短，反之亦然。
• ……

知道了全量發佈的種種弊端，就不得不提灰度發佈的重要性了，這裡引出灰度發佈的定義：

灰度發佈是針對 "全量發佈" 的改進，即按照一定的策略上線部分新版本，同時保留老版本，然後讓部分用戶體驗新版本，通過一段時間新版本的反饋收集，比如：功能、性能、穩定性等指標，然後再決定是否逐步升級直至全量升級或全部回滾到老版本。

灰度發佈的好處：

• 降低發佈影響面： 就算出問題，也只會影響部分用戶，從而可以提前發現出新版本中的問題/ bug，然後在下一次灰度發佈前提前修複，避免影響更多用戶；
• 提升用戶體驗： 除了能提前發現 bug，還能很好的收集新版本中的使用反饋，從而提前優化系統，提升用戶體驗，也能給後續的產品演進帶來參考價值。

灰度發佈分類

灰度發佈的主要分類：

• 金絲雀發佈
• 滾動發佈
• 藍綠發佈

相信大家都或多或少都聽過這些術語的概念，但很多人並不清楚原理及背後的發佈流程，下麵棧長畫了幾張圖，讓大家對這些灰度發佈可以有更深刻的認識。

1）金絲雀發佈

據說以前有個典故，礦工開礦前，會先放一隻金絲雀下去，看金絲雀是否能活下來，用來探測是否有毒氣，金絲雀發佈也是由此得名。

這個典故用在金絲雀發佈上面也是同樣一個道理，即先升級服務一個實例，如果該實例沒有問題，再全部升級剩餘實例，如果有問題，再進行回滾。

金絲雀發佈成本較低，只需要一個實例即可降低新版本存在的風險，適合缺乏足夠的發佈工具研發能力及成長型的小公司。但是，金絲雀發佈也有缺點，當升級全部剩餘實例時，如果流量過多，可能會導致服務中斷。

2）滾動發佈

滾動發佈則是在金絲雀發佈的基礎上進行的改進和優化，第一次也是使用金絲雀發佈，後續則使用多批次的形式發佈剩餘實例，每次批次之間會進行觀察，如果有問題，再進行回滾。

滾動發佈會比較平滑，可以將風險控制到最小程度。它雖然改進了金絲雀發佈，但整體發佈時間會比較長，回退時間也會更慢，整體流程也更為複雜，適合有一定發佈工具研發能力的大公司。

3）藍綠發佈

藍綠發佈比較簡單，只是對全量發佈的一種優化而已，發佈前不用全部停機，而是另外部署新版本全部實例，然後再把流量全部再切換到新版本。

藍綠發佈雖然提升了服務可用性，但沒有解決新版本中可能出現的問題，所以核心業務肯定是不建議用的，建議使用滾動發佈結合金絲雀發佈一起使用，從而降低發佈風險。

4）如何選型

上面介紹了 3 種灰度發佈模式，那麼企業應該怎麼去根據自身的業務場景的訴求，去選型使用哪種模式來進行灰度發佈呢？下麵對各種發佈模式做了一個對比，以及列舉出常見的選型指引，供大家參考。

全量發佈：不建議使用，除非實在沒有辦法，比如初創公司什麼都缺，老闆又催。

藍綠發佈：適合於對於資源預算比較充足的業務，或者是比較簡單的單體應用，可以快速實現系統的整體變更，適合傳統企業使用。

金絲雀和全鏈路灰度：適合需要針對特定用戶或者人群進行現網請求驗證的業務，可以顯著減低風險，建議成長型企業使用。

業界灰度發佈的實現方案

Nacos/ZK + Spring Cloud/dubbo

Nacos 和 ZK 等組件提供的是純註冊中心的功能，不包括灰度發佈的能力。用戶如果需要實現灰度發佈，則需要在框架層通過編碼的方式進行擴展，比如實現 Spring Cloud Gateway/Dubbo 的插件等，帶來的問題主要有 2 個：

• 不同的業務需要重覆造輪子，帶來不必要的工作量和質量風險
• 不同框架實現方式和規則不一樣，存在互通性的問題。

istio

Istio 通過服務網格的方式提供了灰度發佈能力，用戶無需自己實現灰度發佈邏輯，但是也存在以下問題：

• istio 的數據面不支持 Spring Cloud/Dubbo 等常用的微服務框架接入。
• istio + envoy 的 Proxy 模式，運行時會帶來額外的資源和網路開銷。

騰訊雲實現方案（北極星）

基本介紹

先簡單介紹下騰訊雲引擎（TSE）：

微服務引擎（Tencent Cloud Service Engine）提供開箱即用的雲上全場景微服務解決方案。支持開源增強的雲原生註冊配置中心（Zookeeper、Nacos、Etcd、Consul、Eureka 和Apollo），服務治理中心（騰訊自研並開源的 PolarisMesh）、雲原生網關（Nginx Ingress、Kong）以及微服務應用托管的彈性微服務平臺。微服務引擎完全相容開源版本的使用方式，在功能、可用性和可運維性等多個方面進行增強，助力用戶快速構建微服務架構。

北極星（PolarisMesh）是騰訊開源的服務發現和治理中心，以註冊配置中心為基礎，擴展了服務治理功能以及相應的控制面，各部分功能可單獨使用，且支持無侵入的接入方案，用戶無需改一行代碼即可接入所有服務治理功能。

• 基礎： 服務發現、服務註冊、健康檢查、配置管理；
• 擴展： 流量調度（動態路由、負載均衡）、熔斷降級（實例、介面、服務三級熔斷）、訪問控制（限流、鑒權）、可觀測（調用度量、鏈路跟蹤）

可以看到，北極星不僅僅是註冊中心、配置中心，還是微服務架構中的故障容錯、流量控制和安全問題的綜合解決方案。雖然業界已經有些組件可以解決其中一部分問題，但是缺少一個標準的、多語言的、框架無關的實現，北極星應運而生。

實現方案

通過北極星可以實現藍綠、金絲雀或者滾動發佈：

階段一：實例打標

實例打標，指的是發佈前先將實例打入新版本標簽，這樣才能將新版本與穩定舊版本的應用區分開來。

常用的實例打標方法有以下兩種：

• 實例自註冊： 標簽配置在項目的配置文件中，一般是指 Spring Cloud 配置文件中，然後在應用時將標簽自動註冊到註冊中心；

• k8s 部署標簽同步： 把實例標簽作為 k8s 的部署標簽進行配置，然後隨應用部署後自動同步到註冊中心。

階段二：網關路由

服務網關，就是服務的網關，它是所有服務的單一訪問點，並充當微服務最上層的代理。

通俗地說，就是，外面的請求需要先經過服務網關，再到達微服務，服務網關實現統一接入，外面的請求不能直接訪問微服務，一般的訪問順序是這樣的：

用戶 > Nginx（集群，Keepalive） > 服務網關（集群） > 微服務（集群）

所以，要進行灰度發佈就必須在網關層進行路由控制，在網關層可以按照一定的策略把流量分配到不同的實例版本，常用的灰度策略有百分比、用戶屬性、省市區域等等，比如：可以先把廣東省深圳市 30% 的用戶路由到新版本。

一般的服務網關都需要自行配置路由規則，而且都是代碼硬配置，配置項很多很複雜，不是專業的技術人員很難理解其配置的真正意義，也帶來了出錯的概率。

而在騰訊雲北極星方案中，使用的是雲原生網關，支持圖形化的雲原生路由規則配置，支持直通註冊中心，直接將流量拆分到不同版本的實例中，大大簡化了配置難度，也提高了配置項可讀性和易用性。

階段三：微服務路由

來看正常的一個路由流程圖：

流量經過服務網關後，就需要路由到具體的微服務，而灰度發佈後各個微服務存在 V1 舊版本和 V2 新版本，所以就需要保證路由過去的多個微服務調用鏈也必須是同一個版本，不然就可能會帶來災難性故障。

騰訊雲北極星服務治理中心提供了自定義路由的能力，支持通過圖形化配置規則的方式，支持自動托管，以及服務調用流量實時監控能力，準確掌握灰度發佈的全流程，實現了微服務之間的灰度流量調度。

階段四：標簽透傳

上一步，網關層會對灰度流量進行染色，在接下來的微服務調用過程中還需要進行標簽透傳，即將染色標簽在每一個微服務之間進行傳遞，使得微服務可以識別到灰度流量併進行處理。

使用 Spring Cloud 微服務框架，需要用戶自己在項目中進行編碼實現，而騰訊北極星方案可以配合騰訊的 Spring Cloud Tencent 微服務框架自動完成標簽透傳，支持跨線程的透傳模式，無需用戶感知。

階段五：灰度完成

1）灰度發佈驗證

灰度發佈後，如何驗證灰度發佈已經完成/成功了呢？一般需要做以下確認操作：

1）確認流量是否按計劃切換到了灰度發佈實例；

2）確認灰度發佈實例上的請求是否正常執行；

騰訊雲北極星方案提供了服務治理監控能力，支持可視化看到流量實時切換情況，以及流量的成功率時延等關鍵指標，大大簡化了灰度發佈的事後驗證工作。

2）灰度完成後的處理事項

根據不同的灰度發佈形式處理：

金絲雀發佈： 將穩定版本服務分組全量升級成新版本。

滾動灰度： 將穩定版本分組中的多個服務按一定比例分批升級成新版本。

藍綠發佈： 流量已經全量切換到新版本分組，老版本分組的實例可以下線。

北極星開源版體驗

北極星（PolarisMesh）官方網址：

https://polarismesh.cn/

北極星（PolarisMesh）已經開源，點擊主頁右上角可以進入體驗版：

根據提供的預設用戶名和密碼登錄進去，可以在 "服務網格 > 動態路由 > 灰度發佈" 找到灰度發佈：

我們來體驗一下金絲雀發佈吧，操作流程如下：

第一步：實例打標

Spring Cloud Tencent 微服務集成北極星過程略，詳細請參考下麵接入文檔：

https://polarismesh.cn/zh/doc/快速入門/SpringCloud應用接入.html#springcloud應用接入

然後在 bootstrap.yml 配置文件中指定版本標簽：

spring:
  cloud:
    tencent:
      metadata:
        content:
          version: 2.0.0

在服務實例所在的操作系統中添加環境變數也可進行打標，例如：SCT_METADATA_CONTENT_version=2.0.0 。

由於 Spring Cloud 框架預設不會對所有的請求標簽進行透傳，因此需要增加 Spring Cloud 透傳標識，可以通過添加環境變數（SCT_PROTOCOL_CONTENT_TRANSITIVE_HEADER=gray）的方式進行灰度標識（gray:true）的透傳。

第二步：部署應用

Spring Cloud Tencent 接入方式支持虛擬機、Docker Composer、K8S 等多種部署模式，註意需要保證業務進程與北極星服務的網路連通性。

部署後，可以在北極星服務列表中看到成功註冊的服務實例：

第三步：微服務路由

通過配置微服務路由，使進行灰度版本的流量的調用，都只在新版本的服務分組中進行。

可以在 "服務網格 > 動態路由 > 自定義路由" 新建路由規則，先配置灰度規則：

該灰度規則只對 credit 服務生效，這樣 header 中帶有gray:true灰度標簽的請求都只流向version=2.0.0的實例分組。

再來配置兜底規則：

該灰度規則只對 credit 服務生效，這樣 header 中不帶gray:true灰度標簽的請求都只流向version=1.0.0的實例分組。

第四步：灰度發佈觀測

通過北極星的可觀測性能力，可以準確看到不同分組的流量切換的過程，以及服務調用成功率，等到灰度分組相關指標沒有問題，代表灰度驗證完成。

觀測路徑：“可觀測性 > 路由監控”

第五步：灰度發佈收尾

灰度驗證完成後，需要進行收尾：

• 灰度驗證成功，則對老版本分組的實例進行滾動升級到新版本，否則進行回退；
• 在北極星控制台刪除自定義路由規則；

可以看到，北極星提供了一整套的灰度發佈解決方案，適用各種灰度發佈流程，可視化輕鬆實現灰度規則配置，最重要的是還提供灰度可視化觀測，這使得灰度發佈更便利、可控性更好。

總結

看到這裡，想必大家對灰度發佈有了一定程式的認識了，特別是騰訊雲提供的北極星一站式解決方案，通過其獨特的架構理念和可視化平臺解決了微服務應用過程中的種種難題，沒有灰度發佈的加持，全量發佈帶來的風險將變得舉步維艱。

因為用戶體量，或者研發成本的問題，現在很多公司甚至都沒用灰度發佈，全量發佈影響 SLA 不說，一旦造成損失都是不可估量的，所以，不管公司處於什麼成長階段，都必須上灰度發佈，這是對用戶負責，也是公司能持續發展的重要保障。

這裡貼上北極星的 Github 地址，歡迎大家到 Github 上面點個 Star：

https://github.com/polarismesh

作為微服務全面、綜合的開源解決方案，北極星在騰訊內部也得到廣泛運用：

從數據可以看到北極星在騰訊內部使用之廣，這幾乎是覆蓋所有業務了，經過這麼多年的洗禮，北極星也是成熟穩定的項目了，所以，可靠性還是有保障的，可以閉眼使用，不管合適與否，都值得大家去體驗一番。

最後，通過參與這次騰訊雲的 Techo Day 2.0 技術開放日活動，棧長最大的感觸就是，在技術領域，騰訊雲確實走在了前沿，真不是吹，Techo Day 2.0 活動分享了很多技術熱點及解決方案，涵蓋了我們平時開發的方方面面，不僅能學習、接觸新興技術，還能對技術有更多、更深入的認識，特別是棧長介紹的北極星灰度發佈，真真正正的是幫助企業提升項目質量，避免發佈風險。

近期熱文推薦：

1.1,000+ 道 Java面試題及答案整理(2022最新版)

2.勁爆！Java 協程要來了。。。

3.Spring Boot 2.x 教程，太全了！

4.別再寫滿屏的爆爆爆炸類了，試試裝飾器模式，這才是優雅的方式！！

5.《Java開發手冊（嵩山版）》最新發佈，速速下載！

覺得不錯，別忘了隨手點贊+轉發哦！