隨著企業(yè)數(shù)字化轉(zhuǎn)型進程不斷發(fā)展，云原生時代的來臨，企業(yè)應(yīng)用越來越多，不得不面對應(yīng)用程序升級的巨大挑戰(zhàn)。傳統(tǒng)的停機發(fā)布方式，新舊版本應(yīng)用切換少則停機30分鐘，多則停機10小時以上，愈發(fā)無法滿足業(yè)務(wù)端的需求。

“業(yè)務(wù)無感知”的發(fā)布策略成為應(yīng)用運維團隊的不二選擇，盡可能降低發(fā)布對業(yè)務(wù)的影響。“業(yè)務(wù)無感知”的發(fā)布策略有滾動發(fā)布、藍綠發(fā)布、灰度發(fā)布。

本文將從什么是灰度發(fā)布，發(fā)布類型，灰度發(fā)布自動化實踐三個維度來展開。

01. 灰度發(fā)布的概念

灰度發(fā)布，又名金絲雀發(fā)布，即在產(chǎn)品發(fā)布時，先讓一小部分用戶體驗產(chǎn)品新版本的特性，這一小部分用戶的用戶范圍可以是內(nèi)部用戶、測試用戶和非核心用戶，但主要用戶還是繼續(xù)使用產(chǎn)品舊版本

新版本發(fā)布完成之后，驗證業(yè)務(wù)及用戶反饋是否正常，一切正常之后再逐步擴大新版本覆蓋范圍：20%、50%、70%，每發(fā)布一次就進行業(yè)務(wù)驗證、觀察用戶反饋。最后用新版本覆蓋所有用戶，完成一次灰度發(fā)布。

灰度發(fā)布的最大優(yōu)勢是將新版本使用范圍控制在小范圍內(nèi)，如果新版本出現(xiàn)問題，能夠極大降低問題影響范圍，避免影響所有用戶，造成嚴重的生產(chǎn)故障，引發(fā)大范圍的投訴，從而影響到公司業(yè)務(wù)和品牌。

02. 發(fā)布類型

1）滾動發(fā)布：是指一個應(yīng)用有多個主機副本，將其分成多個批次。首先升級第一個批次，之后依次升級其他批次，直到所有批次升級完成。每個批次升級前，需要在LB中移除對應(yīng)主機的流量轉(zhuǎn)發(fā)，升級完成后，再恢復(fù)對應(yīng)主機的流量轉(zhuǎn)發(fā)。

將應(yīng)用分成多個批次，升級前后的LB操作工作量比較大，對應(yīng)用運維人員來說操作麻煩，手工操作出錯的概率較大，嘉為藍鯨應(yīng)用發(fā)布中心，通過自動化流程實現(xiàn)應(yīng)用的滾動發(fā)布。

同時，嘉為藍鯨應(yīng)用發(fā)布中心支持隨機分批和自定義分批兩種方式的滾動發(fā)布。選擇分批方式后，在批次內(nèi)可以選擇串行和并行的執(zhí)行方式

2）藍綠發(fā)布：是指應(yīng)用分為兩個版本，發(fā)布時將舊版本所有流量直接切換到新版本上。新版本部署時，按照舊版本的規(guī)格完全獨立部署一套，部署完成之后，進行簡單測試驗證，正常之后將舊版本的流量直接導(dǎo)到新版本上。

3）灰度發(fā)布：是指應(yīng)用分為兩個版本，發(fā)布時將舊版本的流量，分階段10%、30%、80%、100%切換到新版本上。每階段切換后，任務(wù)需要暫停，應(yīng)用運維人員可以檢查程序是否正常，監(jiān)控日志是否正常，同步業(yè)務(wù)方檢查業(yè)務(wù)指標是否正常。確認一切正常之后，執(zhí)行下一部分發(fā)布動作。

03. 灰度發(fā)布自動化實踐

場景一：基于F5設(shè)備進行藍綠發(fā)布的場景

用戶通過F5設(shè)備控制業(yè)務(wù)流量，將業(yè)務(wù)流量轉(zhuǎn)發(fā)到后端真實應(yīng)用服務(wù)上。為了保證升級時用戶能夠正常訪問，需要進行藍綠發(fā)布。

在進行藍綠發(fā)布時，分成三個發(fā)布步驟：

通過標準運維自動化執(zhí)行切換F5流量的命名，如下：

關(guān)鍵參數(shù)通過變量傳入，該標準運維流程可以被多個業(yè)務(wù)系統(tǒng)復(fù)用，無需每個業(yè)務(wù)系統(tǒng)單獨編排。

場景二：基于Nginx進行灰度發(fā)布的場景

用戶通過Nginx代理或者負載均衡設(shè)備來控制業(yè)務(wù)流量的轉(zhuǎn)發(fā)，為了提高應(yīng)用升級的穩(wěn)定性，升級后先讓部分用戶體驗新版本，通過標準運維腳本命令切換Nginx中流量轉(zhuǎn)發(fā)策略，將小部分隨機用戶流量轉(zhuǎn)發(fā)到新版本服務(wù)上。

確認新版本功能正常后，逐步擴大新版本覆蓋的用戶范圍。避免在藍綠發(fā)布中，新版本異常會影響到所有用戶訪問的問題。

大部分用戶訪問業(yè)務(wù)正常，驗證了新版本的穩(wěn)定性，再讓新版本覆蓋所有用戶，完成基于Nginx的灰度發(fā)布。

具體標準運維任務(wù)參考：

場景三：容器應(yīng)用灰度發(fā)布的場景

容器應(yīng)用在升級時，為了保證業(yè)務(wù)無感知，應(yīng)用運維人員也需要考慮灰度發(fā)布方案，將一次完成的發(fā)布流程，拆分成多個發(fā)布流程，降低每一次應(yīng)用發(fā)布的影響范圍。

容器發(fā)布場景，應(yīng)用一般通過ingress-nginx或者istio控制流量分發(fā)，每次發(fā)布更新ingress中的權(quán)重參數(shù)，實現(xiàn)不同流量比例的切換。

在這個場景中，先部署新應(yīng)用的deploy和service，然后部署ingress，切20%流量到新應(yīng)用，此時發(fā)布任務(wù)暫停，業(yè)務(wù)人員進行應(yīng)用檢查和驗證。驗證業(yè)務(wù)正常之后，再切換40%、70%、100%應(yīng)用到新應(yīng)用上，完成容器應(yīng)用場景的灰度發(fā)布。

場景四：容器應(yīng)用多地域灰度發(fā)布的場景

業(yè)務(wù)應(yīng)用在全國多個省市都有部署，在進行升級時，分地域進行灰度升級。

先升級華東地域應(yīng)用，華東地域內(nèi)串行發(fā)布，確保業(yè)務(wù)能夠正常穩(wěn)定發(fā)布成功；然后依次升級華中地域、華南地域、華北地域、西南地域、港澳臺地域，地域內(nèi)并行發(fā)布執(zhí)行。

場景五：K8s集群版本灰度升級的場景

K8s不支持跨大版本進行升級，如果考慮一個個小版本的升級會非常麻煩，每次小版本升級對應(yīng)用運維人員來說都是非常大的挑戰(zhàn)。因此一個自動化、業(yè)務(wù)無感知的K8s集群版本灰度升級是非常關(guān)鍵的。

業(yè)務(wù)端通過APISIX或者Istio控制業(yè)務(wù)流量。首先自動化部署v1.24版本的K8s集群，然后在v1.24版本集群中部署容器應(yīng)用，通過APISIX灰度遷移少部分業(yè)務(wù)流量，驗證業(yè)務(wù)的可用性和穩(wěn)定性，慢慢將所有應(yīng)用灰度遷移到新版本集群。所有應(yīng)用遷移完成后，將v1.16版本K8s集群下線資源回收。

灰度發(fā)布方案，只是嘉為藍鯨應(yīng)用發(fā)布中心產(chǎn)品支持的一個企業(yè)級發(fā)布場景，其他場景還包含：緊急部署、持續(xù)部署、大規(guī)模變更、應(yīng)用上線等場景，還支持與DevOps、ITSM集成實現(xiàn)研運一體化、工單驅(qū)動變更等功能。詳細產(chǎn)品功能架構(gòu)如下：

嘉為藍鯨應(yīng)用發(fā)布中心核心優(yōu)勢如下：