一、前言

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

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

全量發(fā)布

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

滾動(dòng)發(fā)布

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

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

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

圖片

圖片

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

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

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

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

切除綠集群流量：

圖片

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

圖片

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

灰度發(fā)布

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

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

圖片

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

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

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

圖片

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

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

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

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

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

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

• 日常流量

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

圖片

• 開(kāi)始發(fā)布

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

圖片

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

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

圖片

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

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

圖片

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

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

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

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

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

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

圖片

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

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

圖片

• 發(fā)布完成

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

圖片

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

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

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

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

圖片

1.1 流量規(guī)則SDK

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

1.2 核心能力

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

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

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

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

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

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

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

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

切流事件，藍(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)部流量及外部流量，大部分流量情況如下：

• 外部流量

通過(guò)各類Gateway請(qǐng)求

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

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

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

2.1 RPC

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

圖片

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

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

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

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

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

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

• 如何控制流量比例

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

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

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

圖片

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

權(quán)重值是相對(duì)的，只需要保證藍(lán)、綠集群節(jié)點(diǎn)權(quán)重相對(duì)值服從流量比例即可，無(wú)需同時(shí)修改藍(lán)綠集群所有節(jié)點(diǎn)的權(quán)重。實(shí)例權(quán)重初始值設(shè)為100，修改權(quán)重時(shí)，盡可能保證一半集群實(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。

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

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

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

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

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

將RPC請(qǐng)求第一次進(jìn)入每個(gè)通道時(shí)的藍(lán)綠決策結(jié)果以KV形式Append到分布式Trace的baggage中，全鏈路透?jìng)鳌⒏綦x、復(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)識(shí)，value=藍(lán)集群或綠集群標(biāo)識(shí)，多個(gè)通道以&分割。

圖片

2.2 MQ(RocketMQ)

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

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

• 非摘流狀態(tài)

圖片

• 摘流狀態(tài)

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

圖片

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

• 過(guò)程詳解

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

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

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

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

圖片

2.3 JOB(elasticjob)

圖片

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

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

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

• 過(guò)程詳解

圖片

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

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

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

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

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

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

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

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

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

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

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

圖片

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

圖片

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

前面就說(shuō)過(guò)，藍(lán)綠發(fā)布的一大缺點(diǎn)是通常需要準(zhǔn)備平常流量2倍的資源，以應(yīng)對(duì)藍(lán)綠發(fā)布期間的流量。我們?cè)诩尤胨{(lán)綠發(fā)布集群時(shí)，也盡量會(huì)提醒需要增加資源以應(yīng)對(duì)藍(lán)綠發(fā)布。但如果毫無(wú)規(guī)劃的進(jìn)行擴(kuò)容，則會(huì)帶來(lái)以下幾個(gè)問(wèn)題，比如長(zhǎng)期保留擴(kuò)容資源，則會(huì)帶來(lái)成本的答復(fù)增長(zhǎng)，而臨時(shí)的擴(kuò)容，則代表著對(duì)人力的消耗增加，而且臨時(shí)的擴(kuò)容也增長(zhǎng)了對(duì)資源池管理的難度?？赡茉谟脩魯U(kuò)容時(shí)，出現(xiàn)資源池不足的情況。

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

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

圖片

圖片

圖片

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

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

圖片

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

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

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

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

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

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

比如我們?cè)谄呦Υ蟠倨陂g的發(fā)布，因大促流量過(guò)高，我們?cè)S多服務(wù)在藍(lán)綠發(fā)布時(shí)擴(kuò)容達(dá)到了50%以上的情況，通過(guò)此方式，保證在切流期間，服務(wù)也能正常。

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

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

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

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

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

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

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

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

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

圖片

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

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

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

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

圖片

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

圖片

圖片

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

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

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

未來(lái)展望

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

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