知易行難，雙活過(guò)程中遇到了非常多的問(wèn)題，但是回過(guò)頭看很難完美的表述出來(lái)，之所以這么久才行文也是這個(gè)原因，總是希望可以盡可能的復(fù)現(xiàn)當(dāng)時(shí)的思考、問(wèn)題細(xì)節(jié)及解決方案，但是寫(xiě)出來(lái)才發(fā)現(xiàn)能給出的都是多次打磨、摸索之后的我們認(rèn)為偏合理的方案；不過(guò)換個(gè)角度看，給大家展示出來(lái)一個(gè)正確答案，是否有更積極的參考價(jià)值呢？

以及，涉及到容器、發(fā)布平臺(tái)、底層網(wǎng)絡(luò)運(yùn)維、監(jiān)控等組件的內(nèi)容，限于視野及技術(shù)能力并未包含在內(nèi)，僅聚焦在業(yè)務(wù)團(tuán)隊(duì)及中間件組件的設(shè)計(jì)及改造上。

一、背景

2022年，基于對(duì)穩(wěn)定性的焦慮...和思考，交易平臺(tái)聯(lián)動(dòng)中間件平臺(tái)啟動(dòng)過(guò)異地多活項(xiàng)目的探索，雖然完成了核心應(yīng)用及基礎(chǔ)組件的改造，但在疫情&降本增效的影響下并未真正投產(chǎn)，同時(shí)也缺乏充分的測(cè)試以及線上流量的大規(guī)模驗(yàn)證；后續(xù)在不斷的業(yè)務(wù)迭代中，相關(guān)設(shè)計(jì)及代碼被沖擊的面目全非，相關(guān)的多活自動(dòng)化測(cè)試case也并沒(méi)有沉淀下來(lái)。

隨著近期外部友商時(shí)有嚴(yán)重故障出現(xiàn)，比如

圖片

以上林林總總出現(xiàn)的故障都給我們敲響了警鐘，必須建設(shè)快速恢復(fù)的能力。出現(xiàn)問(wèn)題幾乎不可避免，但如果能控制影響范圍、縮短影響時(shí)間，也就能把損失降到最低。

我經(jīng)歷過(guò)的公司，做交易的和做中間件的往往是最容易焦慮也最容易心態(tài)失衡的兩撥技術(shù)人；一方面所有問(wèn)題都會(huì)暴露在C端用戶面前，影響范圍大且不像toB/toM的場(chǎng)景 避開(kāi)高峰期甚至有可能無(wú)人知曉；另一方面流量高，壓力大，容易面臨突發(fā)流量及突發(fā)事件，穩(wěn)定性這根弦需要始終繃緊；所以往往是面向穩(wěn)定性(的焦慮)設(shè)計(jì)，當(dāng)然熬過(guò)去成長(zhǎng)也最快。

回到我們的現(xiàn)狀，得物目前的交易應(yīng)用及中間件基礎(chǔ)組件都是基于某云部署，且前期為了降低跨機(jī)房調(diào)用產(chǎn)生的網(wǎng)絡(luò)損耗，較多應(yīng)用都綁定了存儲(chǔ)組件(db/redis/hbase)及核心依賴下游的所在可用區(qū)，對(duì)此，為了避免在極端情況下，得物的交易主鏈路出現(xiàn)長(zhǎng)時(shí)間不可用的情況，團(tuán)隊(duì)決定提前預(yù)防，啟動(dòng)同城雙活項(xiàng)目。

為了避免在極端情況下，得物的交易主鏈路出現(xiàn)長(zhǎng)時(shí)間不可用的情況，團(tuán)隊(duì)決定啟動(dòng)同城雙活項(xiàng)目，目標(biāo)是快速建設(shè)流量動(dòng)態(tài)切換能力及快速恢復(fù)能力，同時(shí)降低改造難度、減少改造工作量，不增加大量額外成本。團(tuán)隊(duì)討論決策繞過(guò)之前最復(fù)雜也最容易出問(wèn)題的數(shù)據(jù)同步(db雙向同步、redis雙向同步等)，同時(shí)也不需要在流量切換時(shí)做db禁寫(xiě)，整體具有比較大的可操作可實(shí)施性。

多說(shuō)一句，同城雙活也有做數(shù)據(jù)雙向同步的case，當(dāng)然更徹底--每個(gè)機(jī)房都有全量的數(shù)據(jù)及應(yīng)用，某個(gè)機(jī)房出問(wèn)題 可以完全自閉環(huán)承接流量，不過(guò)帶來(lái)的復(fù)雜度上升、成本上升也會(huì)比較明顯，所以這次并沒(méi)有選擇這條路。換句話說(shuō)，個(gè)人更傾向于小成本低風(fēng)險(xiǎn)快速落地，實(shí)現(xiàn)從0到1的功能建設(shè)，而不是大而全的方案，萬(wàn)一期間遇到問(wèn)題只能徒呼奈何。當(dāng)然在現(xiàn)階段，通過(guò)建設(shè)相對(duì)低風(fēng)險(xiǎn)低投入的同城雙活，積累更多基礎(chǔ)能力的同時(shí)鍛煉團(tuán)隊(duì)，選擇最合適當(dāng)下的方案，解決目前排在第一位的問(wèn)題，怎么想都覺(jué)得還是一件挺劃算的事兒。

畫(huà)一幅簡(jiǎn)圖來(lái)區(qū)分下我們這次同城雙活的方案和業(yè)界異地雙活方案的差異。

異地雙活

圖片

主要特點(diǎn)：

存儲(chǔ)相關(guān)有兩份，雙機(jī)房?jī)?nèi)各自讀寫(xiě)，雙向同步

數(shù)據(jù)的循環(huán)賦值需要重點(diǎn)考慮如何處理

數(shù)據(jù)間的同步延遲問(wèn)題會(huì)比較明顯，不過(guò)各自機(jī)房?jī)?nèi)基本上可自閉環(huán)調(diào)用

對(duì)于用戶、商家資產(chǎn)的處理比較復(fù)雜，比如用戶券、賣(mài)家?guī)齑娴?，一般需要考慮在某個(gè)機(jī)房維護(hù)(gzone)，避免數(shù)據(jù)同步問(wèn)題帶來(lái)的超賣(mài)、超用

切流時(shí)需要做目標(biāo)機(jī)房的局部數(shù)據(jù)禁寫(xiě)，避免臟數(shù)據(jù)產(chǎn)生

同城雙活

圖片

特點(diǎn)：

1. 只有一份數(shù)據(jù)源，不需要考慮數(shù)據(jù)同步的延遲問(wèn)題及切流時(shí)的禁寫(xiě)邏輯，不過(guò)若數(shù)據(jù)所在機(jī)房出問(wèn)題，另一個(gè)機(jī)房無(wú)法正常承接流量(只能承接部分兜底流量，如cdn、緩存等有兜底數(shù)據(jù)的場(chǎng)景)
2. 不需要考慮具備中心節(jié)點(diǎn)性質(zhì)的數(shù)據(jù)問(wèn)題，如用戶券、庫(kù)存等
3. 跨機(jī)房訪問(wèn)較多，尤其是數(shù)據(jù)層面的讀寫(xiě)，可能會(huì)造成RT的大幅上漲

不管是同城還是異地、雙活還是多活(雙活只是多活里最簡(jiǎn)單的場(chǎng)景，雙活到三活難度飆升范圍應(yīng)該不亞于<羊了個(gè)羊>里第一關(guān)和第二關(guān)的難度)，都是為了以下目標(biāo)：

1. 提高可靠性：通過(guò)在不同的物理位置部署服務(wù)，減少單點(diǎn)故障的風(fēng)險(xiǎn)。即使一個(gè)機(jī)房發(fā)生故障，其他機(jī)房也可以接管服務(wù)，確保業(yè)務(wù)連續(xù)性。
2. 負(fù)載均衡：可以靈活分配用戶請(qǐng)求流量，避免單個(gè)機(jī)房過(guò)載，尤其隨著業(yè)務(wù)規(guī)模的擴(kuò)大單個(gè)云廠商的機(jī)房已經(jīng)無(wú)力提供更多資源的情況下。
3. 災(zāi)難恢復(fù)：通過(guò)流量的調(diào)度切換來(lái)快速恢復(fù)某個(gè)機(jī)房的故障問(wèn)題，減少業(yè)務(wù)中斷時(shí)間。
4. 云成本：在技術(shù)成熟度較高的前提下，做同云、跨云 甚至云+自建IDC機(jī)房之間的多活，一方面可以降低對(duì)某個(gè)云廠商的依賴從而獲取一定的議價(jià)權(quán)；另一方面多活本身在提高資源利用率方面可以有更多可能性。
5. 提高服務(wù)質(zhì)量：這點(diǎn)尤其表現(xiàn)在異地多活場(chǎng)景，通過(guò)在多個(gè)中心之間分配流量，可以減少網(wǎng)絡(luò)延遲，提供更快的響應(yīng)時(shí)間和更高的服務(wù)質(zhì)量。

二、設(shè)計(jì)思路

一句話描述：在云機(jī)房的多個(gè)可用區(qū)(即多個(gè)物理機(jī)房)中構(gòu)造應(yīng)用層面的雙集群部署，配合目前已經(jīng)在交易鏈路大規(guī)模上線的藍(lán)綠發(fā)布，完成流量的動(dòng)態(tài)切換(含HTTP、RPC、DMQ[rocketmq/kafka])。而存儲(chǔ)(redis/db)還是在單機(jī)房(但是可以跨機(jī)房部署)，降低方案及實(shí)現(xiàn)的復(fù)雜度。

三、雙活整體架構(gòu)

圖片

可以看到，整體在架構(gòu)層面分為四層：

• 接入層：DNS 域名解析+ SLB主備 + DLB+DAG多機(jī)房部署，保障接入層高可用。其中在DAG中實(shí)現(xiàn)了根據(jù)用戶ID、流量比例等控制藍(lán)綠流量的策略。
• 應(yīng)用層： 應(yīng)用通過(guò)改造，劃分為邏輯藍(lán)綠集群，通過(guò)藍(lán)綠同調(diào)的粘性屏蔽跨區(qū)調(diào)用。
• 中間件層：多個(gè)中間件組件有各自不同的跨AZ部署策略、數(shù)據(jù)同步、主動(dòng)切換策略，下面會(huì)詳述。
• 數(shù)據(jù)層：數(shù)據(jù)層保持一份數(shù)據(jù)，通過(guò)自動(dòng)/手動(dòng)主從切換，跨區(qū)部署等技術(shù)手段，保障機(jī)房級(jí)別故障下服務(wù)可用，包含DB、Redis、Hbase等。

四、具體改造方案

本次雙活涉及到三個(gè)主要部分，分別是：交易應(yīng)用側(cè)雙活改造、交易依賴方應(yīng)用雙活改造、中間件&基礎(chǔ)組件改造。下面分別介紹：

交易應(yīng)用側(cè)雙活改造

1. 項(xiàng)目范圍

交易側(cè)默認(rèn)所有服務(wù)均參與同城雙活改造，一方面內(nèi)部應(yīng)用之間的調(diào)用關(guān)系復(fù)雜，區(qū)分處理梳理工作量極高；另一方面快速的業(yè)務(wù)迭代也會(huì)改變互相之間的依賴關(guān)系，維護(hù)這套邏輯成本太高；以及，內(nèi)部強(qiáng)弱依賴本身也在動(dòng)態(tài)變化，讓團(tuán)隊(duì)的同學(xué)不斷的識(shí)別哪些應(yīng)該雙活、哪些應(yīng)該單點(diǎn)，溝通和執(zhí)行成本反而更高。

2.業(yè)務(wù)改造思路及方案

實(shí)際業(yè)務(wù)場(chǎng)景中復(fù)雜的鏈路拓?fù)渥罱K可以抽象為如下典型的、原子的鏈路拓?fù)?A-B-C)的疊加、組合。

圖片

A、C服務(wù)參與雙活，需要跨可用區(qū)部署。B服務(wù)不參與雙活，不需要跨可用區(qū)部署。

A、B、C服務(wù)都需要識(shí)別流量染色、服從流量調(diào)度。

• 相關(guān)服務(wù)Owner各自將服務(wù)中集成的統(tǒng)一基礎(chǔ)框架升級(jí)到指定版本，接入無(wú)侵入、零配置、開(kāi)箱即用的藍(lán)綠發(fā)布能力組件全家桶。保證基于藍(lán)綠發(fā)布的運(yùn)行時(shí)流量調(diào)度能力被完整集成。上述簡(jiǎn)圖中A、B、C服務(wù)需要進(jìn)行該步驟。
• 相關(guān)服務(wù)Owner各自在發(fā)布平臺(tái)界面白屏化遷移發(fā)布模式。發(fā)布模式遷移到藍(lán)綠發(fā)布時(shí)，發(fā)布平臺(tái)自動(dòng)將服務(wù)Pod進(jìn)行跨可用區(qū)部署，并在Pod中注入支撐流量調(diào)度的進(jìn)程級(jí)元信息。藍(lán)綠發(fā)布能力組件在上游調(diào)用方LoadBalance時(shí)介入進(jìn)行流量染色、流量調(diào)度。上述簡(jiǎn)圖中A、C服務(wù)需要進(jìn)行該步驟。

完成上述改造后，雙活鏈路上的流量呈現(xiàn)就近調(diào)用、可用區(qū)封閉的特點(diǎn)，即：流量染色后，后續(xù)鏈路上的每一跳調(diào)用都會(huì)優(yōu)先向下游服務(wù)集群中與流量同色(同可用區(qū))的實(shí)例發(fā)起調(diào)用。

交易依賴方應(yīng)用雙活改造

僅僅依靠交易側(cè)應(yīng)用，無(wú)法完成所有的P0鏈路，如下單時(shí)依賴供應(yīng)鏈側(cè)時(shí)效。強(qiáng)依賴的外域服務(wù)同樣納入了同城雙活改造范圍。其改造點(diǎn)基本一致，不再贅述。

中間件&基礎(chǔ)組件

識(shí)別機(jī)器資源可用區(qū)

項(xiàng)目初期，我們發(fā)現(xiàn)容器POD和ECS缺少可用區(qū)標(biāo)識(shí)，導(dǎo)致無(wú)法區(qū)分對(duì)應(yīng)的資源歸屬。于是我們配合運(yùn)維組和監(jiān)控組的同事制定了一份規(guī)范。在環(huán)境變量里給機(jī)器都打上對(duì)應(yīng)的標(biāo)記，同時(shí)這也是監(jiān)控和日志能透出機(jī)房標(biāo)記的基石。

中間件RTO

同城雙活要求中間件在單個(gè)可用區(qū)出問(wèn)題的時(shí)候，仍能對(duì)外提供服務(wù)。其設(shè)計(jì)目標(biāo)的RTO為以下：

主要組件雙活改造方案

01.DLB - 自研流量網(wǎng)關(guān) 

圖片

DLB是無(wú)狀態(tài)組件，在兩個(gè)可用區(qū)對(duì)等部署。

當(dāng)其中一個(gè)可用區(qū)故障時(shí)，在SLB的endpoints上故障節(jié)點(diǎn)會(huì)被剔除，流量會(huì)打到正常的節(jié)點(diǎn)，實(shí)現(xiàn)故障快速恢復(fù)的目標(biāo)。預(yù)計(jì)秒級(jí)完成。

02.彩虹橋 - 自研分布式關(guān)系數(shù)據(jù)庫(kù)代理

圖片

彩虹橋目前不具備自動(dòng)流量切換能力，一方面自動(dòng)切換過(guò)于復(fù)雜，另一方面也容易帶來(lái)更多的風(fēng)險(xiǎn)，以及也依賴DB層面的主備切換，所以走手動(dòng)切換，預(yù)計(jì)分鐘級(jí)完成。

目前流量99%走A區(qū)集群、1%的流量走B區(qū)集群，當(dāng)A區(qū)發(fā)生可用區(qū)故障時(shí)，可手動(dòng)把流量全部調(diào)度至B區(qū)集群，同時(shí)需要DB層完成主備切換(a->b)。

03.DMQ

圖片

通過(guò)Broker分片級(jí)別打散到不同的可用區(qū)形成一套完整的集群。

當(dāng)可用區(qū)故障時(shí)，集群可用分片會(huì)減少一半，集群整體可用。

DMQ的改造經(jīng)過(guò)了多次試錯(cuò)，最開(kāi)始通過(guò)在消費(fèi)端創(chuàng)建多個(gè)consumer group的方式實(shí)現(xiàn)，但需要業(yè)務(wù)側(cè)配合多次升級(jí)處理，且會(huì)導(dǎo)致消費(fèi)端存在雙倍的consumer group，后面才決定將主要改造工作放在rocketmq broker內(nèi)部。簡(jiǎn)要介紹如下：

藍(lán)綠屬性

BROKER中的隊(duì)列設(shè)定成偶數(shù)，并且>=2。我們把前一半隊(duì)列視為邏輯上的藍(lán)色隊(duì)列，后一半隊(duì)列視為綠色隊(duì)列(這里也可以看到，雙活里的很多處理邏輯都是非此即彼，但是如果到多活，復(fù)雜度就會(huì)更高)。

圖片

生產(chǎn)者

在進(jìn)行隊(duì)列選擇時(shí)，根據(jù)集群環(huán)境藍(lán)綠顏色進(jìn)行分組選擇：

• 藍(lán)集群的消息會(huì)被投遞的broker的前一半隊(duì)列中
• 綠集群的消息會(huì)被投遞到broker的后一半隊(duì)列中

在每種選擇邏輯內(nèi)部是按照輪循的方式進(jìn)行選擇，不破壞生產(chǎn)者本身支持的容錯(cuò)邏輯。

消費(fèi)者

消費(fèi)者也是類似。藍(lán)色消費(fèi)者消費(fèi)藍(lán)色隊(duì)列的消息。綠色消費(fèi)者消費(fèi)綠色隊(duì)列的消息。

04.Kafka

由于ZK的ZAB協(xié)議要求保證 Math.floor(n/2)+1 奇數(shù)個(gè)節(jié)點(diǎn)存活才能選出主節(jié)點(diǎn)，所以 ZK 需要進(jìn)行3個(gè)可用區(qū)部署，上面的nameserver類似。分散在3個(gè)可用區(qū)中，A:B:C 節(jié)點(diǎn)數(shù) =  2N:2N:1，確保始終是奇數(shù)個(gè)集群節(jié)點(diǎn)。

Broker 在兩個(gè)可用區(qū)對(duì)等部署，分區(qū)的主從跨區(qū)部署。當(dāng)單個(gè)可用區(qū)故障時(shí)，分區(qū)leader切換。

05.ES

ES多可用區(qū)部署，需要區(qū)分?jǐn)?shù)據(jù)節(jié)點(diǎn)和master節(jié)點(diǎn)。

• 數(shù)據(jù)節(jié)點(diǎn)：需要保持各個(gè)可用區(qū)之間節(jié)點(diǎn)對(duì)等，以保證數(shù)據(jù)的平衡；使用分區(qū)感應(yīng)把主副分片隔開(kāi)，保持在不同可用區(qū)內(nèi)。

圖片

• master節(jié)點(diǎn)：部署在至少三個(gè)可用區(qū)，以保證任何一個(gè)可用區(qū)掛了，都不影響master的選舉。

圖片

06.注冊(cè)中心

PS：自研分布式注冊(cè)中心，基于raft協(xié)議實(shí)現(xiàn)系統(tǒng)可用性、數(shù)據(jù)一致性。承擔(dān)得物全站RPC服務(wù)發(fā)布/訂閱職責(zé)。

圖片

1. 代理節(jié)點(diǎn)多分區(qū)部署，保障多可用區(qū)雙活
2. Sylas集群Raft節(jié)點(diǎn)3個(gè)分區(qū)部署，保障多可用區(qū)雙活

流量分配策略

01.RPC流量

雙活的RPC的入口流量在DAG上進(jìn)行調(diào)整，DAG會(huì)盡量根據(jù)用戶ID進(jìn)行流量分配。

1. 每個(gè)應(yīng)用會(huì)在請(qǐng)求上下文中附上當(dāng)前的藍(lán)綠標(biāo)識(shí)；
2. 如果某個(gè)應(yīng)用沒(méi)有納入雙活范疇，這里的藍(lán)綠標(biāo)識(shí)會(huì)丟失，此時(shí)有兩種策略：

a. 隨機(jī)分配，不過(guò)會(huì)破壞鏈路的純潔性；

b. 根據(jù)userID再算一次，不過(guò)需要增加一次對(duì)ark配置的處理。

圖片

02.MQ流量比例

因?yàn)樗{(lán)綠集群的生產(chǎn)者和消費(fèi)者對(duì)隊(duì)列進(jìn)行了綁定。所以只要調(diào)整藍(lán)綠生產(chǎn)者的消息比例就可以調(diào)整整個(gè)MQ的消費(fèi)流量比例。而藍(lán)綠生產(chǎn)者的消息比例一般由RPC流量決定。所以調(diào)整RPC的流量比例，MQ的流量比例也會(huì)得到相應(yīng)的調(diào)整。不過(guò)會(huì)有一定的滯后(5-10s)。

五、上線環(huán)節(jié)

前期準(zhǔn)備階段

整體思路確定：

• 基于當(dāng)前的藍(lán)綠發(fā)布做雙活，每次的藍(lán)綠發(fā)布過(guò)程就是一次雙活切流演練，避免長(zhǎng)久不使用，需要用的時(shí)候手忙腳亂或者年久失修
• 服務(wù)層做雙活部署，數(shù)據(jù)層不做大的改造，DB和Redis通過(guò)自身的主從切換實(shí)現(xiàn)高可用，從節(jié)點(diǎn)分布在不同的可用區(qū)
• 交易域內(nèi)所有服務(wù)+核心鏈路相關(guān)外域服務(wù)做雙活改造

梳理所有業(yè)務(wù)場(chǎng)景、MQ情況、容器部署現(xiàn)狀、數(shù)據(jù)庫(kù)&緩存主從節(jié)點(diǎn)可用區(qū)現(xiàn)狀：

• 交易域所有服務(wù)&以及核心業(yè)務(wù)場(chǎng)景強(qiáng)依賴的外部服務(wù)、強(qiáng)依賴的具體業(yè)務(wù)場(chǎng)景、可否降級(jí)&有無(wú)兜底
• MQ使用情況：DMQ還是Kafka還是其他、是否需要保證消息的順序性
• 所有服務(wù)當(dāng)前機(jī)器所在可用區(qū)、是否綁定固定可用區(qū)
• 交易域所有數(shù)據(jù)庫(kù)、Redis對(duì)應(yīng)的主節(jié)點(diǎn)和從節(jié)點(diǎn)分別所在可用區(qū)情況
• 依賴zookeeper的job情況

評(píng)估改動(dòng)范圍：

• 上下游非交易域溝通確認(rèn)（必須納入改造范圍的服務(wù)、可以不用雙活改造的服務(wù)必須要有兜底）
• 雙活涉及到的服務(wù)jar升級(jí)、未接入藍(lán)綠發(fā)布的接入藍(lán)綠發(fā)布
• 跨區(qū)調(diào)用情況下RT上漲明顯的接口針對(duì)性優(yōu)化

部分業(yè)務(wù)場(chǎng)景是否需要接入自建Redis的就近讀改造：

• 運(yùn)維側(cè)提供自建Redis的就近讀方案，但是對(duì)于數(shù)據(jù)一致性方面有所犧牲，各方根據(jù)實(shí)際業(yè)務(wù)場(chǎng)景和接口RT情況綜合評(píng)估是否需要接入

開(kāi)發(fā)&驗(yàn)證階段

服務(wù)jar升級(jí)：支持雙活藍(lán)綠切流、支持MQ藍(lán)綠發(fā)送&消費(fèi)

雙活藍(lán)綠染色測(cè)試環(huán)境搭建、測(cè)試流程改善

• 環(huán)境本身的搭建：服務(wù)藍(lán)綠集群拆分、綁定可用區(qū)、容器藍(lán)綠集群機(jī)器比例配置
• 雙活藍(lán)綠染色環(huán)境代碼版本校驗(yàn)、代碼準(zhǔn)入規(guī)則、分支自動(dòng)合并規(guī)則、測(cè)試流程流轉(zhuǎn)等
• 將雙活藍(lán)綠染色環(huán)境定為測(cè)試二輪round2環(huán)境，在日常迭代中常態(tài)化回歸驗(yàn)證雙活流程

雙活藍(lán)綠染色測(cè)試環(huán)境回歸

• 正常業(yè)務(wù)流程回歸
• 測(cè)試環(huán)境藍(lán)綠切流回歸
• 測(cè)試環(huán)境MQ生產(chǎn)&消費(fèi)切流回歸
• 核心業(yè)務(wù)接口RT情況記錄對(duì)比、優(yōu)化意見(jiàn)

雙活染色環(huán)境全局通道打開(kāi)情況下藍(lán)綠發(fā)布通道切流回歸

• 驗(yàn)證通道優(yōu)先級(jí)：發(fā)布通道優(yōu)先級(jí) > 全局通道

預(yù)發(fā)環(huán)境集群拆藍(lán)綠

• 此刻預(yù)發(fā)環(huán)境等于已經(jīng)實(shí)際上完成了雙活改造

預(yù)發(fā)環(huán)境驗(yàn)證&RT問(wèn)題重點(diǎn)關(guān)注

線上所有雙活改造服務(wù)單獨(dú)拆一臺(tái)機(jī)器到B區(qū)觀察&驗(yàn)證RT上漲問(wèn)題

• 交易平臺(tái)絕大部分服務(wù)之前都是綁定可用區(qū)A區(qū)，每個(gè)服務(wù)單獨(dú)部署一臺(tái)機(jī)器到B區(qū)，觀察接口RT情況

DMQ升級(jí)藍(lán)綠2.0支持按照藍(lán)綠標(biāo)消費(fèi)

線上準(zhǔn)備&上線階段

日志平臺(tái)、監(jiān)控平臺(tái)、trace鏈路、容器升級(jí)支持藍(lán)綠標(biāo)

生產(chǎn)環(huán)境DMQ切換為藍(lán)綠2.0支持按照雙活藍(lán)綠標(biāo)消費(fèi)

數(shù)據(jù)庫(kù)&Redis主節(jié)點(diǎn)切換，保證主從節(jié)點(diǎn)只在A區(qū)或者B區(qū)

• 大部分在在a、b這兩個(gè)區(qū)，也有例外。核心是主節(jié)點(diǎn)一定要在這兩個(gè)區(qū)

線上服務(wù)拆分藍(lán)綠集群（手動(dòng)），項(xiàng)目正式上線，回歸驗(yàn)證&RT問(wèn)題關(guān)注

綠集群（A區(qū)）擴(kuò)容至100%機(jī)器，藍(lán)集群（B區(qū)）維持50%機(jī)器，灰度觀察5天

線上RT上漲接口技術(shù)專項(xiàng)優(yōu)化

發(fā)布平臺(tái)雙活保障迭代升級(jí)

• 支持新增服務(wù)一鍵加入雙活藍(lán)綠集群

圖片

• 雙活藍(lán)綠集群支持按區(qū)批量擴(kuò)容能力（單機(jī)房故障情況下，快速拉起存活區(qū)的服務(wù)）

容器平臺(tái)支持容器管控多可用區(qū)部署

六、項(xiàng)目成果

2023年12月14日，籌備近100天的交易鏈路同城雙活完成上線，經(jīng)過(guò)5天(12.14-12.18)的觀察及圣誕前高流量(DLB流量達(dá)到雙十一的77.8%)的驗(yàn)證，確認(rèn)無(wú)明顯異常，之后線上集群完成縮容。部分場(chǎng)景的RT有一定比例的上漲(數(shù)據(jù)層面只做了跨可用區(qū)容災(zāi)，但是并沒(méi)有實(shí)現(xiàn)就近訪問(wèn)，所以藍(lán)集群的所有數(shù)據(jù)層面調(diào)用都需要跨可用區(qū))，已啟動(dòng)技術(shù)小項(xiàng)目推動(dòng)優(yōu)化中。

從實(shí)際效果上看，經(jīng)過(guò)12.22的大版本發(fā)布過(guò)程中的跨機(jī)房切流，交易鏈路已經(jīng)具備跨機(jī)房流量調(diào)度的能力，如下：

圖片

流量表現(xiàn)

（A區(qū) - 綠集群，B區(qū) - 藍(lán)集群)

• 兩個(gè)可用區(qū)的集群流量達(dá)到了50:50。不過(guò)rocketmq 由于存在少量上下游應(yīng)用并未進(jìn)行多活改造，還有較小流量未嚴(yán)格分布

圖片

• 核心指標(biāo) qps/rt/錯(cuò)誤率

• 核心基礎(chǔ)組件訪問(wèn)情況由于所有數(shù)據(jù)存儲(chǔ)(db、redis、hbase)均在A區(qū)，故B區(qū)的 rt 有一定上漲，整體看上浮大概 7-8ms( 存在一次請(qǐng)求 查詢多次數(shù)據(jù)的場(chǎng)景)，還在持續(xù)推動(dòng)優(yōu)化

成本情況

因A區(qū)原有云資源均為包年包月模式，停止使用依然會(huì)有費(fèi)用產(chǎn)生；同時(shí)在B區(qū)部署服務(wù)穩(wěn)定性支撐50%流量之前，存在5天的并行期（A區(qū)100%資源、B區(qū)50%資源，共150%），期間共產(chǎn)少量成本。

灰度并行期結(jié)束后，A區(qū)資源釋放掉50%，整體成本回歸原有平均線，無(wú)額外成本產(chǎn)生。

七、帶來(lái)的新問(wèn)題及后續(xù)

1. 藍(lán)綠發(fā)布中，如果下游接入了雙活但沒(méi)有進(jìn)入發(fā)布通道，消費(fèi)流量會(huì)傾斜，比如在上游切換流量過(guò)程中，RPC或MQ會(huì)優(yōu)先本可用區(qū)調(diào)用，也就是另一個(gè)可用區(qū)流量比例會(huì)受影響；需要關(guān)注每個(gè)可用區(qū)中冗余的容量評(píng)估是否可以支撐全量流量。

2. RT變化，對(duì)于下游未加入雙活、或者某些存儲(chǔ)/緩存中間件，如DB/Hbase/Redis未開(kāi)啟就近讀取，B機(jī)房的RT會(huì)普遍高5-8ms。已在逐步投入優(yōu)化。

3. 容器管控作為基礎(chǔ)設(shè)施，在出現(xiàn)機(jī)房級(jí)故障的時(shí)候需要保證正常運(yùn)行，能夠順利完成擴(kuò)縮容操作，即容器管控面的多可用區(qū)部署，這塊目前還在建設(shè)中。

4. 機(jī)房級(jí)故障情況下，單機(jī)房批量擴(kuò)容快速拉起，是否有足夠的可用資源（尤其是大促期間，云廠商本身資源就吃緊）。

5. 多個(gè)大域之間的雙活聯(lián)動(dòng)問(wèn)題，比如交易和搜推

• 兩個(gè)大域雙活切流是否需要聯(lián)動(dòng)（聯(lián)動(dòng)：影響范圍被放大，且搜推側(cè)擴(kuò)容不易；不聯(lián)動(dòng)：各域雙活流量非常割裂）
• 兩個(gè)大域之間的是否識(shí)別相同的藍(lán)綠標(biāo)（各大域內(nèi)部自閉環(huán)保證同區(qū)訪問(wèn)or大域之間也需要保證）

6. 如何在線上無(wú)損情況下進(jìn)行一次貼近實(shí)際的演練。

以上問(wèn)題都是在雙活之后帶來(lái)的新挑戰(zhàn)，也都在不斷的思考及投入解決。

不管做什么，不管怎么做，人生總會(huì)有新的問(wèn)題出現(xiàn)，不是么？Keep a long-term view lol...