前言
大家好，我是堆疊長，
最近，堆疊長又參加了騰訊云小伙伴邀請的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開發手冊（嵩山版）》最新發布，速速下載！
覺得不錯，別忘了隨手點贊+轉發哦！
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/524915.html
標籤：其他