一、前言

發(fā)布變更是影響穩(wěn)定性的一個重大因素，為了發(fā)布異常時能快速回滾，增加發(fā)布期間的穩(wěn)定性，也為了解決多服務(wù)部署時互相依賴而導(dǎo)致的發(fā)布時間增長等問題，得物在今年引入一種新的發(fā)布模式--藍(lán)綠發(fā)布。這種發(fā)布模式帶來了穩(wěn)定性和效率的提升，這里我們以SRE的視角來解讀下得物的藍(lán)綠發(fā)布。

二、常見的發(fā)布形式有哪些？分別有什么優(yōu)勢？

全量發(fā)布

全量發(fā)布是早期企業(yè)進(jìn)行系統(tǒng)升級的一種方式，因?yàn)樵缙诘姆?wù)大多為大型機(jī)，單實(shí)例程序?yàn)橹鳌２]有形成當(dāng)下流行的微服務(wù)架構(gòu)，因此當(dāng)發(fā)布時往往需要停機(jī)發(fā)布。生產(chǎn)環(huán)境禁止使用這種方式進(jìn)行部署！

滾動發(fā)布

滾動發(fā)布顧名思義，假如生產(chǎn)中16臺機(jī)器，我們可以分成4批。每批4臺機(jī)器，每批機(jī)器執(zhí)行更新，從版本V1更新為V2，更新后重新將其投入使用，連續(xù)不斷的更新其他機(jī)器，直到集群中所有的實(shí)例都更新為版本B后，結(jié)束發(fā)布。

這種方式的好處就是更新過程體驗(yàn)影響少，費(fèi)用開銷也少，發(fā)布期間無需額外新增機(jī)器。但是缺點(diǎn)也同樣明顯，一旦開始發(fā)布后，回滾時長很久，在多個有關(guān)聯(lián)的服務(wù)部署時，需要上游服務(wù)完全發(fā)布后，才能發(fā)布下游服務(wù)，整體發(fā)布時間也很長。

滾動發(fā)布流程演示：

圖片

圖片

藍(lán)綠發(fā)布

通常意義上的藍(lán)綠發(fā)布一般是將服務(wù)分為兩組，藍(lán)組和綠組，正常運(yùn)轉(zhuǎn)的情況下每組承載50%的流量。當(dāng)準(zhǔn)備發(fā)布服務(wù)時, 將藍(lán)組流量設(shè)置為0%，將綠組空閑出來，將服務(wù)部署到綠組的機(jī)器，然后利用SLB將流量切換到綠組的機(jī)器，讓綠組來運(yùn)行業(yè)務(wù)，沒問題的話流量全部導(dǎo)向綠組，把藍(lán)組也進(jìn)行服務(wù)更新。

傳統(tǒng)意義上的藍(lán)綠發(fā)布優(yōu)點(diǎn)在于發(fā)布策略簡單，對于用戶幾乎無感知，可以實(shí)現(xiàn)平滑過度，在發(fā)布期間發(fā)現(xiàn)問題后也可以快速的回滾。而缺點(diǎn)則是通常需要準(zhǔn)備正常業(yè)務(wù)使資源倆倍以上的服務(wù)器，需要投入較大的資源成本。

藍(lán)綠發(fā)布流程演示：

切除綠集群流量：

圖片

當(dāng)A組升級完畢，負(fù)載均衡重新接入A組，再把B組從負(fù)載列表中摘除，進(jìn)行新版本的部署，A組重新提供服務(wù)。

圖片

最后，B組也升級完成，負(fù)載均衡重新接入B組，此時，AB組版本都已經(jīng)升級完成，并且都對外提供服務(wù)。

灰度發(fā)布

灰度發(fā)布，也被叫作金絲雀發(fā)布。與藍(lán)綠部署、紅黑部署不同的是，灰度發(fā)布屬于增量發(fā)布方法。也就是說，服務(wù)升級的過程中，新舊版本會同時為用戶提供服務(wù)。

灰度發(fā)布的具體流程是這樣的：在集群的一小部分機(jī)器上部署新版本，給一部分用戶使用，以測試新版本的功能和性能；確認(rèn)沒有問題之后，再對整個集群進(jìn)行升級。簡單地說，灰度發(fā)布就是把部署好的服務(wù)分批次、逐步暴露給越來越多的用戶，直到最終完全上線。

圖片

之所以叫作灰度發(fā)布，是因?yàn)樗橛诤谂c白之間，并不是版本之間的直接切換，而是一個平滑過渡的過程。

AB Test就是一種灰度發(fā)布方式，讓一部分用戶繼續(xù)用A，一部分用戶開始用B，如果用戶對B沒有什么反對意見，那么逐步擴(kuò)大范圍，把所有用戶都遷移到B上面來。灰度發(fā)布可以保證整體系統(tǒng)的穩(wěn)定，在初始灰度的時候就可以發(fā)現(xiàn)并調(diào)整問題，以保證其影響度，而我們平常所說的金絲雀部署也就是灰度發(fā)布的一種方式。

之所以又被叫作金絲雀發(fā)布，是因?yàn)榻鸾z雀對瓦斯極其敏感，17 世紀(jì)時英國礦井工人會攜帶金絲雀下井，以便及時發(fā)現(xiàn)危險。這就與灰色發(fā)布過程中，先發(fā)布給一部分用戶來測試相似，因而得名。

圖片

對于灰度發(fā)布來說，它的優(yōu)點(diǎn)在于如果前期出問題影響范圍很小，相對用戶體驗(yàn)也少；可以做到及時發(fā)現(xiàn)、及時調(diào)整問題，影響范圍可控。但是采取這種模式對自動化以及運(yùn)維監(jiān)控能力的要求非常高。

三、得物的藍(lán)綠發(fā)布是如何實(shí)現(xiàn)的？

前面講了“what”，我們現(xiàn)在來說下“how”。

在平時，我們也會保留藍(lán)綠兩個集群，在發(fā)布時，引入灰度的流量平滑過度，幫助我們完成整個發(fā)布過程，下面以SRE的視角大致講一下藍(lán)綠發(fā)布的架構(gòu)與流程。

藍(lán)綠發(fā)布的流程

在這種架構(gòu)下，整體的發(fā)布流程如下：

• 日常流量

在未發(fā)布時，我們接入藍(lán)綠發(fā)布的服務(wù)是平均分成藍(lán)綠倆個集群的。平時通過網(wǎng)關(guān)均勻切分流量，平均每個集群50%的流量。

圖片

• 開始發(fā)布

當(dāng)進(jìn)行藍(lán)綠發(fā)布時，我們將需要發(fā)布的應(yīng)用創(chuàng)建在一個通道中(這里先說下只有一個通道部署的情況)。

圖片

• 藍(lán)集群(右側(cè))摘流

此時所有流量將只訪問綠集群，如下圖所示，當(dāng)藍(lán)集群摘流完成后, 此時集群沒有任何流量，即可進(jìn)行部署。

圖片

• 藍(lán)集群(右側(cè))引流

當(dāng)藍(lán)集群發(fā)布完成后，我們需要對藍(lán)集群發(fā)布后的服務(wù)進(jìn)行確認(rèn)。在確認(rèn)部署成功后，則梯度的將流量引入更新后代碼的藍(lán)集群(右側(cè))，最開始我們會切1%的流量，切流量后，我們可以在線上觀察藍(lán)服務(wù)的流量、錯誤率等。以此觀測發(fā)布的版本是否有異常。之后，我們逐漸將流量切回50%。注意，需要確保相關(guān)缺陷都在該環(huán)節(jié)暴露出來，因?yàn)檫@個環(huán)節(jié)另一半老版本的、穩(wěn)定的代碼還在Standby，可以隨時操作流量比例，進(jìn)行流量遷移。

圖片

發(fā)布過程中，藍(lán)、綠節(jié)點(diǎn)間流量不會互竄(對比上圖，藍(lán)綠集群間斜向箭頭沒有了)。

此階段需要注意MQ流量，因?yàn)镸Q當(dāng)前無法按比例進(jìn)行切分，因此一旦開始切流，則MQ流量會恢復(fù)為50%/50%。

• 綠集群(左側(cè))摘流

通過擴(kuò)大流量比例，流量全部切到藍(lán)集群，這個階段流量已全部切到新代碼，可以讓測試同學(xué)介入進(jìn)行新功能驗(yàn)證以及回歸測試。

在這個階段只要綠集群還沒發(fā)布，發(fā)現(xiàn)問題，仍然可以全部切回老代碼！

當(dāng)測試驗(yàn)證完成后，即可進(jìn)行綠集群發(fā)布。發(fā)布后則不可以回切了！就算要代碼回滾，也得等本次發(fā)布結(jié)束后,再單獨(dú)對服務(wù)進(jìn)行回滾。

圖片

• 綠集群(左側(cè))引流

在發(fā)布后則開始進(jìn)入綠集群引流了，此時可以快速引流，因?yàn)橐呀?jīng)沒有可以回滾的、穩(wěn)定版本的代碼了。同樣，還在發(fā)布階段，及時流量均衡，也不會出現(xiàn)互相交叉的流量。

圖片

• 發(fā)布完成

發(fā)布完成后，則去除通道，藍(lán)綠集群可以繼續(xù)進(jìn)行交互。

圖片

如上圖所示，使用以上發(fā)布流程具備以下好處：

• 整個發(fā)布過程是以藍(lán)、綠集群維度并行調(diào)度、實(shí)施的，通過發(fā)布平臺統(tǒng)一操作，摘流，無需各業(yè)務(wù)域各自處理。
• 通過請求藍(lán)綠粘性，讓下游應(yīng)用的新老版本代碼可以同時存在，無需阻塞等待下游應(yīng)用全部升級到新代碼，解除了批次依賴。
• 發(fā)布過程中有靈活的流量控制能力，可以按1%、50%等階梯流量驗(yàn)證應(yīng)用。
• 上述發(fā)布流程，可以同時并存若干個，摘流、引流動作互不影響(多發(fā)布通道)。

藍(lán)綠發(fā)布的架構(gòu)

應(yīng)用架構(gòu) [1]

圖片

1.1 流量規(guī)則SDK

在所有需要接入藍(lán)綠發(fā)布的程序中，首先需要升級流量規(guī)則SDK，流量規(guī)則SDK是應(yīng)用藍(lán)綠發(fā)布能力的代碼底座，向中間件組件如RPC、MQ、JOB提供了主動查詢流量規(guī)則和被動接受流量規(guī)則變更事件的能力，各中間件組件響應(yīng)流量規(guī)則進(jìn)行合適的動作，實(shí)現(xiàn)各類型流量的動態(tài)摘流、動態(tài)引流。

1.2 核心能力

• 依賴配置中心做持久化存儲與事件推送。
• 所有配置讀取都是內(nèi)存操作，只會在啟動時讀取一次配置中心的配置，后續(xù)配置變更都依賴于配置中心的事件推送。
• 提供了如下的能力：

當(dāng)前應(yīng)用所在的發(fā)布通道，是否在藍(lán)綠發(fā)布中。

指定應(yīng)用所在的發(fā)布通道，是否在藍(lán)綠發(fā)布中。

藍(lán)色流量百分比，范圍[0, 100]。

• 提供了如下的事件推送：

發(fā)布開始事件onStart。

發(fā)布結(jié)束事件onFinish。

切流事件onFlowChange，切流事件又細(xì)分了以下幾個事件。

切流事件，藍(lán)色流量標(biāo)占比為100，綠色流量標(biāo)占比為0，onEnterAllBlue。

切流事件，藍(lán)色流量標(biāo)占比從100改為非100，綠色流量標(biāo)占比從0改為非0，onExitAllBlue。

切流事件，藍(lán)色標(biāo)流量占比為0，綠色流量標(biāo)占比為100，onEnterAllGreen。

切流事件，藍(lán)色標(biāo)流量占比從0改為非0，綠色流量標(biāo)占比從100改為非100，onExitAllGreen。

流量控制

得物目前的流量分為內(nèi)部流量及外部流量，大部分流量情況如下：

• 外部流量

通過各類Gateway請求

通過k8s Ingress請求(暫不支持藍(lán)綠發(fā)布)

• 內(nèi)部流量
• 通過Gateway互聯(lián)
• 通過Dubbo/Feign RPC協(xié)議互聯(lián)
• 通過MQ異步請求
• 通過kafka異步請求(暫不支持)
• JOB類任務(wù)發(fā)起的流量
• 通過k8s  SVC請求(暫不支持藍(lán)綠發(fā)布)

其中Gateway也是通過Dubbo或者Feign請求下游服務(wù)，因此也可統(tǒng)一為RPC類型，所以得物目前的流量主要包含RPC、MQ、JOB三種。

2.1 RPC

我們RPC流量核心主要依賴注冊中心，通過Dubbo的負(fù)載均衡策略進(jìn)行調(diào)整。

圖片

• 如何實(shí)現(xiàn)RPC流量比例控制

RPC場景下應(yīng)用的流量比例控制，取決于它的上游應(yīng)用按照流量規(guī)則比例向其發(fā)起調(diào)用。核心是上游應(yīng)用感知到下游應(yīng)用實(shí)例權(quán)重。

當(dāng)前應(yīng)用通過流量規(guī)則SDK監(jiān)聽到所在通道的流量規(guī)則變更時，修改注冊中心上的實(shí)例權(quán)重。

上游應(yīng)用通過注冊中心透明的感知下游應(yīng)用的實(shí)例權(quán)重，通過加權(quán)負(fù)載均衡策略實(shí)現(xiàn)流量比例控制。

Dubbo原生的各類負(fù)載均衡策略都支持加權(quán)，也就是即便上游沒有升級藍(lán)綠依賴，下游應(yīng)用依然可以通過藍(lán)綠實(shí)例權(quán)重控制自己藍(lán)綠集群被調(diào)用的比例。

Feign原生是不支持的，F(xiàn)usion框架重寫了負(fù)載均衡策略。

• 如何控制流量比例

藍(lán)色流量比例Rate，藍(lán)色集群實(shí)例權(quán)重WB，綠色集群實(shí)例權(quán)重WG。

假設(shè)Rate從1調(diào)整到99，一共有4個節(jié)點(diǎn)。

調(diào)整前WB=1，WG=99，調(diào)整后WB=99，WG=1，可能出現(xiàn)以下情況：

圖片

•  流量規(guī)則變更時，只讓藍(lán)或綠某一個集群修改自己的權(quán)重。

權(quán)重值是相對的，只需要保證藍(lán)、綠集群節(jié)點(diǎn)權(quán)重相對值服從流量比例即可，無需同時修改藍(lán)綠集群所有節(jié)點(diǎn)的權(quán)重。實(shí)例權(quán)重初始值設(shè)為100，修改權(quán)重時，盡可能保證一半集群實(shí)例權(quán)重保持100不變，只修改另一側(cè)被調(diào)整的集群實(shí)例的權(quán)重。

規(guī)則如下：

藍(lán)色流量比例Rate，公式：W/(100+W) = Rate/100。

Rate = 50，藍(lán)色集群實(shí)例權(quán)重=100，綠色集群實(shí)例權(quán)重=100。

Rate < 50，藍(lán)色集群實(shí)例權(quán)重=100 * Rate / (100-Rate)，綠色集群實(shí)例權(quán)重=100。

Rate > 50，藍(lán)色集群實(shí)例權(quán)重=100，綠色集群實(shí)例權(quán)重=100 * Rate1 / (100-Rate1)，其中Rate1=100 - Rate。

• 只有一個顏色的集群時，忽略權(quán)重。
• 如何實(shí)現(xiàn)完全摘流

Dubbo框架內(nèi)置的所有負(fù)載均衡策略都會識別下游實(shí)例的權(quán)重進(jìn)行加權(quán)篩選節(jié)點(diǎn)，無需上游升級依賴，下游應(yīng)用實(shí)例權(quán)重置0后即可實(shí)現(xiàn)摘流。

Feign框架默認(rèn)不識別實(shí)例權(quán)重，不進(jìn)行加權(quán)負(fù)載均衡，為了避免藍(lán)綠發(fā)布項(xiàng)目落地時推動發(fā)布鏈路上下游應(yīng)用升級的困難，應(yīng)用摘流時，會將自身注冊的所有Feign服務(wù)反注冊，以保證Feign流量能被徹底摘流。

• 如何實(shí)現(xiàn)請求鏈路藍(lán)綠粘性(一藍(lán)到底或一綠到底)

藍(lán)綠子集群的代碼是不一樣的，按我們制定的發(fā)布流程，藍(lán)集群是新代碼，綠集群是老代碼，如果不能固定請求鏈路的顏色，實(shí)現(xiàn)請求過程一藍(lán)到底或者一綠到底，那么可能會出現(xiàn)上游新代碼調(diào)用到下游老代碼，出現(xiàn)代碼不兼容的異常。

將RPC請求第一次進(jìn)入每個通道時的藍(lán)綠決策結(jié)果以KV形式Append到分布式Trace的baggage中，全鏈路透傳、隔離、復(fù)用。

如果Trace中有藍(lán)綠決策結(jié)果，則按照藍(lán)綠決策結(jié)果篩選節(jié)點(diǎn)；

否則按照流量比例篩選節(jié)點(diǎn)，并將決策結(jié)果（節(jié)點(diǎn)集群顏色）Append到Trace。

baggage-key: x-deploy-channel-type。

baggage-value：key=通道標(biāo)識，value=藍(lán)集群或綠集群標(biāo)識，多個通道以&分割。

圖片

2.2 MQ(RocketMQ)

核心是通過多消費(fèi)組實(shí)現(xiàn)MQ流量隔離和控制。業(yè)務(wù)上創(chuàng)建的一個業(yè)務(wù)消費(fèi)組，會在MQ SDK層面透明的創(chuàng)建2個衍生的顏色消費(fèi)組。

發(fā)送消息時，會在消息頭上攜帶當(dāng)前節(jié)點(diǎn)藍(lán)綠標(biāo)。3個消費(fèi)組收到消息時，根據(jù)消息顏色和消費(fèi)組顏色做顏色請和判斷，互斥的消費(fèi)同一個TOPIC上的所有消息。

• 非摘流狀態(tài)

圖片

• 摘流狀態(tài)

應(yīng)用感知到通道內(nèi)藍(lán)集群摘流時，藍(lán)集群節(jié)點(diǎn)關(guān)閉消費(fèi)組、綠集群節(jié)點(diǎn)啟動三種顏色消費(fèi)組。此時，MQ流量完全由綠集群接管。

圖片

通道內(nèi)綠集群摘流時同理。

• 過程詳解

原本一個消費(fèi)組，拆分成三個消費(fèi)組。

原始消費(fèi)組origin-consumer用于消費(fèi)無（藍(lán)綠）標(biāo)識的流量。

藍(lán)色消費(fèi)組blue-consumer用于消費(fèi)「藍(lán)色」標(biāo)識流量。

綠色消費(fèi)組green-consumer用于消費(fèi)「綠色」標(biāo)識流量。

圖片

2.3 JOB(elasticjob)

圖片

elasticjob在運(yùn)行時會在業(yè)務(wù)應(yīng)用集群內(nèi)利用ZK協(xié)調(diào)產(chǎn)生一個Master節(jié)點(diǎn)，由Master節(jié)點(diǎn)來按負(fù)載均衡策略將任務(wù)分配到各個執(zhí)行器節(jié)點(diǎn)上。這個任務(wù)分配關(guān)系一經(jīng)分配就會固定并在后續(xù)復(fù)用，除非是有應(yīng)用進(jìn)程上下線、JOB分片數(shù)有變更。

改造elasticjob客戶端適配流量規(guī)則SDK，正在藍(lán)綠發(fā)布的應(yīng)用，在感知到有集群已經(jīng)摘流時，會修改ZK上的狀態(tài)標(biāo)識，將上述記錄的分配關(guān)系失效。

失效后，后續(xù)JOB執(zhí)行時，會根據(jù)流量規(guī)則重新進(jìn)行任務(wù)分配，避讓已經(jīng)摘流的節(jié)點(diǎn)，以保證已經(jīng)摘流的節(jié)點(diǎn)上不會有JOB執(zhí)行。

• 過程詳解

圖片

藍(lán)綠接入注意事項(xiàng)

因當(dāng)前技術(shù)限制, 服務(wù)接入藍(lán)綠需要注意以下事項(xiàng)：

• 流量無法摘除的服務(wù)暫時無法接入

未通過網(wǎng)關(guān)進(jìn)入服務(wù)流量：例如，通過域名SLB進(jìn)入服務(wù)、通過Ingress進(jìn)入服務(wù)的流量無法摘除。

消費(fèi)Kafka的流量無法摘除：由于應(yīng)用使用的原生kafka客戶端并全面鋪開、無法對切入提供支持。

未使用統(tǒng)一框架/注冊中心：未使用統(tǒng)一框架和注冊中心的Java應(yīng)用、以及非Java類應(yīng)用當(dāng)前不支持藍(lán)綠發(fā)布。

• 使用特別提醒
• 消費(fèi)消息需冪等：使用消息中間件必須做冪等，這是基本要求，在消費(fèi)組啟停管控中可能產(chǎn)生重復(fù)消息。
• 消費(fèi)組線程數(shù)量：由于會有三個消費(fèi)組、消費(fèi)線程也會增加兩倍，有業(yè)務(wù)影響時需調(diào)低線程數(shù)。
• 需要好流量評估：藍(lán)綠發(fā)布需一半節(jié)點(diǎn)承接線上流量、在應(yīng)用升級藍(lán)綠集群時做好確認(rèn)。
• 升級到特定版本：使用藍(lán)綠發(fā)布需要應(yīng)用升級到框架指定版本，詳見接入指南。
• Feign/HTTP流量：針對使用框架Feign的HTTP流量，需上下游應(yīng)用全部升級后方可使用。
• 使用Dubbo流量：使用框架Dubbo的服務(wù)只需要自身服務(wù)升級版本即可、無需上下游升級。

四、得物SRE團(tuán)隊(duì)對藍(lán)綠發(fā)布的相關(guān)支持

容器集群針對藍(lán)綠的改造

我們?nèi)萜鞯膚orkload使用的OpenKruise來進(jìn)行管理。在進(jìn)行藍(lán)綠發(fā)布之前，我們使用的單個clonesets進(jìn)行控制。

以下圖所示，為我們一個測試非藍(lán)綠集群，這里就是使用單個cloneset進(jìn)行控制的單實(shí)例。

圖片

在進(jìn)行藍(lán)綠改造后，我們將workload分為藍(lán)綠兩個clonesets，通過這樣，我們可以實(shí)現(xiàn)藍(lán)綠發(fā)布時候的單邊實(shí)例發(fā)布。同時在我們管理平臺界面，任是單個集群界面， 以此來實(shí)現(xiàn)單集群下 藍(lán)綠集群的拆分。

圖片

藍(lán)綠發(fā)布擴(kuò)容資源優(yōu)化

前面就說過，藍(lán)綠發(fā)布的一大缺點(diǎn)是通常需要準(zhǔn)備平常流量2倍的資源，以應(yīng)對藍(lán)綠發(fā)布期間的流量。我們在加入藍(lán)綠發(fā)布集群時，也盡量會提醒需要增加資源以應(yīng)對藍(lán)綠發(fā)布。但如果毫無規(guī)劃的進(jìn)行擴(kuò)容，則會帶來以下幾個問題，比如長期保留擴(kuò)容資源，則會帶來成本的答復(fù)增長，而臨時的擴(kuò)容，則代表著對人力的消耗增加，而且臨時的擴(kuò)容也增長了對資源池管理的難度。可能在用戶擴(kuò)容時，出現(xiàn)資源池不足的情況。

為了應(yīng)對這個問題，我們針對藍(lán)綠發(fā)布進(jìn)行了優(yōu)化。首先是在發(fā)布流程中加入了擴(kuò)縮容的環(huán)節(jié)。讓平臺自動幫助進(jìn)行服務(wù)的擴(kuò)縮容。其次，在容器層面，我們利用云服務(wù)商的彈性實(shí)例功能，來彌補(bǔ)常規(guī)資源池不足的情況，通過基于Virtual Kubelet技術(shù)接入到k8s中，支持秒級啟動，按量計費(fèi)，可快速完成擴(kuò)縮容，滿足業(yè)務(wù)的實(shí)時響應(yīng)需求。

注意:  在應(yīng)用加入發(fā)布通道時，因藍(lán)綠發(fā)布會導(dǎo)致流量減半，請務(wù)必對核心服務(wù)進(jìn)行擴(kuò)容(SRE建議擴(kuò)容30%以上)。

圖片

圖片

圖片

發(fā)布監(jiān)控

加入灰度的藍(lán)綠發(fā)布，因?yàn)樯婕傲髁壳袚Q過程，因此對監(jiān)控要求非常高，需要及時觀測整個通道中的服務(wù)狀態(tài)，而歷史中單應(yīng)用的監(jiān)控頁面無法滿足發(fā)布o(jì)wner有效觀測。因此，針對這個問題，我們專門設(shè)計了通道級的藍(lán)綠發(fā)布大盤，有效的觀測流量分布情況，服務(wù)的請求情況等。通過該大盤，發(fā)布o(jì)wner能有效掌握本次發(fā)布情況，決定是否繼續(xù)進(jìn)行切流。

圖片

五、藍(lán)綠發(fā)布期間可能出現(xiàn)的問題及應(yīng)急響應(yīng)策略

資源不足導(dǎo)致的服務(wù)異常

• 發(fā)布前擴(kuò)容

根據(jù)藍(lán)綠發(fā)布原理可知，我們在發(fā)布時，只有50%的實(shí)例來支撐原先100%的流量， 因此務(wù)必在藍(lán)綠發(fā)布前勾選發(fā)布前臨時擴(kuò)容。擴(kuò)容量需要評估以下幾個數(shù)據(jù)：

• 服務(wù)CPU 水位情況

根據(jù)歷史經(jīng)驗(yàn)，如日常水位99值在20%以內(nèi)的服務(wù)，無需進(jìn)行臨時擴(kuò)容，而99值在20%-30以內(nèi)的服務(wù)，建議擴(kuò)容20%左右。而99值在30-40%之間的服務(wù)，應(yīng)當(dāng)擴(kuò)容30%以上。同時也要考慮發(fā)布當(dāng)天的流量情況。

比如我們在七夕大促期間的發(fā)布，因大促流量過高，我們許多服務(wù)在藍(lán)綠發(fā)布時擴(kuò)容達(dá)到了50%以上的情況，通過此方式，保證在切流期間，服務(wù)也能正常。

因?yàn)槲覀兊姆?wù)大多以JAVA為主，內(nèi)存大多用固定方式分配給了JVM堆，因此內(nèi)存不是一個核心的參考指標(biāo)。

• 服務(wù)線程使用情況

除了服務(wù)CPU外，服務(wù)線程也是一個核心參考指標(biāo)，特別是Dubbo線程池以及DB/Redis的線程池。比如原先Dubbo線程池，max為 200,10個實(shí)例的服務(wù)，當(dāng)日常QPS大于1000的時候，在藍(lán)綠發(fā)布時就需要擴(kuò)容了，否則實(shí)例數(shù)少了一半，意味著可用線程也少了一半，這個時候就會出現(xiàn)線程拒絕異常了。

• 發(fā)布期間的資源不足

有些時候，我們評估不足會導(dǎo)致在開始發(fā)布后因?yàn)橘Y源不足導(dǎo)致的錯誤率上升，此時需要我們緊急處理，但為了發(fā)布期間的穩(wěn)定性，一旦我們開啟了藍(lán)綠通道，就不允許進(jìn)行集群的擴(kuò)容了。此時需要SRE接入在后臺進(jìn)行處理，處理邏輯如下：

• 確認(rèn)待擴(kuò)容集群未處于發(fā)布狀態(tài)。
• 手動修改藍(lán)/綠單邊集群cloneset的replicas數(shù)據(jù)。
• 待發(fā)布完畢后，手動還原該cloneset的replicas數(shù)據(jù)。

因該操作非標(biāo)準(zhǔn)操作，且存在風(fēng)險，請盡量不要使用以上方式進(jìn)行。

發(fā)布中出現(xiàn)流量不均衡的情況

之前的一次測試中，我們在引流后出現(xiàn)了服務(wù)流量不均衡的問題，當(dāng)時因?yàn)镕usion框架升級了Dubbo異步的改造中存在邏輯缺陷，導(dǎo)致流量無法均衡分布。之后，通過回退Fusion框架版本后問題恢復(fù)。

圖片

這是個比較危險的情況，某些節(jié)點(diǎn)會在發(fā)布時承擔(dān)日常400%的流量，很容易造成服務(wù)雪崩。因此，在藍(lán)綠發(fā)布中，負(fù)責(zé)人和SRE要加強(qiáng)服務(wù)的監(jiān)控和關(guān)注力度，及時發(fā)現(xiàn)流量不均衡的情況并介入。

發(fā)布中出現(xiàn)流量互竄的情況

流量互竄的問題會有許多種情況：有因?yàn)榍辛髑暗腏OB持續(xù)運(yùn)行，導(dǎo)致雙邊集群依舊有流量；有的因?yàn)殒溌分虚g節(jié)點(diǎn)沒有升級藍(lán)綠能力，導(dǎo)致流量錯位；有的因?yàn)镸Q請求下游導(dǎo)致的流量錯位。這里不針對問題進(jìn)行一一分析，問題的解決僅能依靠框架的升級，這里僅說下問題的影響和排查方法。

在藍(lán)綠發(fā)布時，原先我們的預(yù)計是老代碼連老代碼，新代碼連新代碼，但出現(xiàn)異常請求時，可能出現(xiàn)新代碼連老代碼，或者老代碼連下游新代碼的情況，這個時候就會出現(xiàn)因?yàn)橐蕾嚥黄ヅ洌瑢?dǎo)致的服務(wù)異常。

圖片

要發(fā)現(xiàn)此類問題，我們首先要知道，在這種情況下，大多會出現(xiàn)單邊集群錯誤率上升。通過我們的監(jiān)控頁面，我們能很好的發(fā)現(xiàn)單邊錯誤率上升的情況。此時，我們就能根據(jù)這些錯誤的情況，在天眼的調(diào)用鏈分析中，查看錯誤的具體情況。此時需要我們判斷鏈路里是否有出現(xiàn)流量異常的情況，查看節(jié)點(diǎn)的Host name，可以判斷是藍(lán)或者綠集群節(jié)點(diǎn)。

圖片

圖片

六、歷史總結(jié)及展望未來

藍(lán)綠發(fā)布的效果

自從交易域進(jìn)行藍(lán)綠發(fā)布以來，平均大版本的發(fā)布時效較之前得到了較大的提升，同時近期大版本已沒有出現(xiàn)故障事件，在升級藍(lán)綠發(fā)布后，我們可以提前在切流階段發(fā)現(xiàn)問題，并快速回切進(jìn)行修復(fù)，避免了故障帶入生產(chǎn)。因此，現(xiàn)在藍(lán)綠發(fā)布相比過去滾動部署，在效率和穩(wěn)定性上均大有提升。

未來展望

目前我們核心服務(wù)都已切換至藍(lán)綠集群，這種為我們的多活打下了優(yōu)勢，已經(jīng)天然具備了多活的條件。因此，未來我們可以通過這種架構(gòu)來部署我們的多活，這樣，當(dāng)任何單機(jī)房出現(xiàn)異常后，能夠快速切換到另外一個機(jī)房，我們的抗風(fēng)險能力也會有巨大的提升。參考引用:

[1] 特別鳴謝，本節(jié)藍(lán)綠發(fā)布架構(gòu)及原理部分引用了得物中間件平臺 “羊羽”同學(xué)的文章。