一、高可用多活架構(gòu)

相較于傳統(tǒng)的災(zāi)備單活的架構(gòu)，多活指的是在同城或異地的一個(gè)數(shù)據(jù)中心建立一套與本地生產(chǎn)系統(tǒng)部分或完全對(duì)應(yīng)的一套服務(wù)，再進(jìn)行流量調(diào)度，使所有可用區(qū)的一個(gè)應(yīng)用同時(shí)對(duì)外提供服務(wù)。

災(zāi)難發(fā)生時(shí)，借助多活的業(yè)務(wù)快速實(shí)現(xiàn)流量切換，可以避免或大幅降低用戶受到故障的影響。較為典型的兩種方案類型主要包括同城多活和異地多活。

1.高可用整體架構(gòu)

2.多活的方案類型

我們使用螞蟻的CRG多活定義類型，CRG分別代表GZone 、RZone、CZone的三種模式。

• GZone模式

用戶間的數(shù)據(jù)可以共享，比如B站的視頻播放、番劇播放、稿件信息直播間等數(shù)據(jù)偏向于平臺(tái)側(cè)，這類業(yè)務(wù)場(chǎng)景都可以做成GZone模式。

• RZone模式

單元化模式，它更適用于用戶側(cè)的流水型數(shù)據(jù)，比如社區(qū)的評(píng)論、彈幕、動(dòng)態(tài)及支付，比較適合做成Rzone模式。

• CZone模式

介于GZone和 RZone之間，做用戶間的數(shù)據(jù)共享，但它支持在當(dāng)?shù)氐亩嗫捎脜^(qū)內(nèi)可讀可寫，并且能夠接受一定的數(shù)據(jù)延遲和不一致性。

B站具有多個(gè)數(shù)據(jù)中心，但整體定位比較混亂，所以我們?cè)诙嗷顖?chǎng)景里重新做了梳理和劃分。

以上海的機(jī)房為例，我們有4個(gè)機(jī)房，整體分為了2個(gè)可用區(qū)，用來(lái)做我們GZone的服務(wù)部署。因?yàn)閮蓚€(gè)可用區(qū)都在上海，一般延時(shí)情況都在一毫秒左右，所以在同城雙活方面無(wú)需擔(dān)心出現(xiàn)網(wǎng)絡(luò)延時(shí)問(wèn)題。這也是目前主要在推進(jìn)的一個(gè)業(yè)務(wù)改造覆蓋的方案。

另外，我們還在江蘇設(shè)置機(jī)房，作為 RZone的服務(wù)部署，但由于距離上海較近，無(wú)法模擬出遠(yuǎn)端異地高延遲的情況，同時(shí)容災(zāi)能力存在不足。因此，目前我們?nèi)栽隍?yàn)證在華南或是在一些L2、L3的邊緣機(jī)房進(jìn)行的異地多活的方案，后文將詳細(xì)介紹。

1)同城多活

同城多活是指我們通過(guò)流量調(diào)度，在應(yīng)用多數(shù)據(jù)中心的同時(shí)，對(duì)外提供服務(wù)。同城多活的機(jī)房距離較近，所以耗時(shí)一般會(huì)控制在5毫秒以內(nèi)，在數(shù)據(jù)層面具備主從同步和切換的能力。因?yàn)橥嵌嗷畹木W(wǎng)絡(luò)延時(shí)比較低，所以在業(yè)務(wù)改造過(guò)渡的階段，服務(wù)的調(diào)用不會(huì)增加過(guò)多耗時(shí)。

2）異地多活

異地多活也是通過(guò)流量調(diào)度，同時(shí)對(duì)外提供多數(shù)據(jù)中心的服務(wù)。

如果是距離比較遠(yuǎn)的兩個(gè)機(jī)房，那么全程耗時(shí)可能會(huì)達(dá)到30毫秒以上。這方面很難使用單集群的模式來(lái)提供服務(wù)，而多集群的模式下，又會(huì)因數(shù)據(jù)一致性的復(fù)雜度造成問(wèn)題。

通常有兩種解決方案，一種是要求業(yè)務(wù)進(jìn)行單元化的改造，它需要具備單元數(shù)據(jù)的分片能力，而單元間需要雙向同步數(shù)據(jù)；另一種是面向一些可以接受延遲的業(yè)務(wù)，它們?cè)谥骺捎脜^(qū)可寫可讀，然后在異地建立一個(gè)只讀的單元，支持讀的流量分流。

3） B站的同城多活

因?yàn)楹芏鄶?shù)據(jù)都偏向于用戶間共享，所以B站的很多業(yè)務(wù)適合做成同城多活。下圖為B站同城多活的架構(gòu)圖，由一個(gè)流量層即DCDN層面，對(duì)用戶維度的一些信息來(lái)進(jìn)行Hash路由，然后進(jìn)行請(qǐng)求分發(fā)。

目前，B站主要是基于向用戶的一個(gè)MID或者是用戶的一些設(shè)備ID來(lái)做路由，分發(fā)到不同的可用區(qū)，不同可用區(qū)的用戶能夠訪問(wèn)在該可用區(qū)的緩存，比如KV存儲(chǔ)和DB存儲(chǔ)。這兩個(gè)存儲(chǔ)通過(guò)Proxy模式訪問(wèn)，可以就近讀本機(jī)房，寫可回源到上?？捎脜^(qū)一。另外，這套方案中又加了一個(gè)Invoker組件，進(jìn)行多活的全局管控。

①流量接入層

我們通常將流量的管控面分為南北向，即從用戶側(cè)到我們內(nèi)部服務(wù)的方向。另一方向是東西向，一般指內(nèi)網(wǎng)的服務(wù)間調(diào)用的流量。其中南北向這個(gè)部分就是由我們的DCDN、SLB，也就是7層負(fù)載，還有API網(wǎng)關(guān)。

在實(shí)際的架構(gòu)中，用戶從端上過(guò)來(lái)訪問(wèn)，會(huì)基于DNS或是HTTP DNS來(lái)訪問(wèn)我們的DCDN的節(jié)點(diǎn)，在DCDN回源時(shí)會(huì)有POP點(diǎn)來(lái)做流量的匯聚，再進(jìn)入到我們的可用區(qū)。我們的DCDN基于邊緣CDN節(jié)點(diǎn)來(lái)做整體的路由管控，實(shí)現(xiàn)動(dòng)態(tài)的最佳選路。

我們自研了一個(gè)Picker模塊，可支持用戶的一個(gè)MID或者是設(shè)備ID Hash到不同的可用區(qū)，同時(shí)支持用戶流量權(quán)重在多機(jī)房進(jìn)行全動(dòng)態(tài)和靈活的調(diào)整，99:1或日常的50:50都可以靈活定義。至于7層負(fù)載SLB，它能通過(guò)服務(wù)發(fā)現(xiàn)多可用區(qū)的下游服務(wù)和APIGW的節(jié)點(diǎn)，支持API的降級(jí)和全局限流的能力。

APIGW本身是一個(gè)容器部署的服務(wù)，和我們內(nèi)部其他BFF層一樣，支持發(fā)現(xiàn)多可用區(qū)的服務(wù)節(jié)點(diǎn)，所以我們將其放在了南北向和東西向流量銜接的這一層，使它支持單可用區(qū)服務(wù)的故障重試。目前我們也逐步將SLB側(cè)的管控能力轉(zhuǎn)移到GW層面統(tǒng)一進(jìn)行管理，它可以支持服務(wù)的API降級(jí)、熔斷和限流，包括我們和客戶端聯(lián)動(dòng)的流控能力，避免服務(wù)故障時(shí)客戶端瘋狂重試導(dǎo)致進(jìn)一步壓垮服務(wù)。

APIGW也部署于PaaS平臺(tái)，支持HPA彈性擴(kuò)容，可以應(yīng)對(duì)一些流量突增的情況。

Discovery是我們的服務(wù)發(fā)現(xiàn)組件，在服務(wù)啟動(dòng)后，它會(huì)向注冊(cè)中心進(jìn)行注冊(cè)，并且定期更新Review，同時(shí)對(duì)服務(wù)下游依賴的信息如HTTP或者是GRPC的地址端口，及其可用區(qū)的信息進(jìn)行拉取和緩存。

在調(diào)用下游時(shí)，客戶端即SDK層面會(huì)默認(rèn)選取同可用區(qū)的一個(gè)節(jié)點(diǎn)。若下游在該可用區(qū)未做部署，比如一些非多活的業(yè)務(wù)，則會(huì)回到主可用區(qū)調(diào)用。所以在同城多活的場(chǎng)景下，要求服務(wù)能夠在本地完整地支持寫請(qǐng)求的處理，以及強(qiáng)弱依賴必須在本地進(jìn)行部署，而弱依賴則會(huì)被允許應(yīng)用跨專線回主機(jī)房。另外，Discovery也能對(duì)東西向的流量權(quán)重進(jìn)行管理，包括一些灰度驗(yàn)證等。

②緩存一致性

為避免業(yè)務(wù)直連緩存實(shí)例，緩存接入方面我們提供統(tǒng)一的Proxy。SDK 在各開發(fā)語(yǔ)言上并不統(tǒng)一，所以可能會(huì)引發(fā)短連接的風(fēng)暴，并引起性能下降。我們通過(guò)用Proxy來(lái)長(zhǎng)連接緩存實(shí)例，Proxy支持 Sidecar和ProxylessSDK等模式提供接入。B站緩存的使用場(chǎng)景不支持多機(jī)房的同步，在多活場(chǎng)景下要求服務(wù)訂閱同機(jī)房的一個(gè)數(shù)據(jù)源，對(duì)緩存進(jìn)行數(shù)據(jù)更新或者刪除，維護(hù)緩存數(shù)據(jù)最終的一致性。

• 保證緩存一致性的處理方式

Cache Aside的模式即DB/KV的存儲(chǔ)加上緩存，因?yàn)閿?shù)據(jù)最終都會(huì)落到存儲(chǔ)上，所以這類情況下業(yè)務(wù)只需要通過(guò)Canal訂閱同可用區(qū)存儲(chǔ)Binlog變更然后投遞消息隊(duì)列，由業(yè)務(wù)的的Job解析處理后刪除或更新緩存。

• 純緩存場(chǎng)景

一類是熱數(shù)據(jù)的情況，業(yè)務(wù)在多可用區(qū)可能通過(guò)Job定時(shí)刷新，把數(shù)據(jù)從DB或者是其他的離線數(shù)據(jù)源中拉取，隨后存放到緩存中。在多活情況下，這類場(chǎng)景要求獨(dú)立部署，再通過(guò)job做定時(shí)更新，目的是使業(yè)務(wù)和緩存在單個(gè)可用區(qū)內(nèi)實(shí)現(xiàn)閉環(huán)的調(diào)用。

另一類就是將緩存當(dāng)做存儲(chǔ)的用法，這個(gè)用法一般不推薦，出于性能考慮，B站不支持做持久化的緩存場(chǎng)景。若作為存儲(chǔ)使用，即使是Cache Aside這樣的模式，在遇到一些較大規(guī)模的故障時(shí)，仍舊會(huì)出現(xiàn)數(shù)據(jù)丟失的情況。

所以在這方面建議業(yè)務(wù)改造為Cache Aside的模式，或者是通過(guò)KV進(jìn)行存儲(chǔ)。KV是B站自研的分布式KV存儲(chǔ)系統(tǒng)，本身的數(shù)據(jù)存儲(chǔ)在SSD中，所以它的性能必然不如Redis Cluster內(nèi)存的性能有優(yōu)勢(shì)。但我們做過(guò)評(píng)估，當(dāng)業(yè)務(wù)的QPS小于10萬(wàn)，基本上可以遷移到我們的KV存儲(chǔ)系統(tǒng)內(nèi)。KV存儲(chǔ)也支持Redis協(xié)議的一些常用命令和操作，它的最大特性是支持機(jī)房的多活。

• 分布式鎖場(chǎng)景

例如涉及一些分布式鎖或者說(shuō)處理冪等，這類情況就建議把業(yè)務(wù)改造為KV。因?yàn)镵V本身支持如Cache這樣的命令，并且它的數(shù)據(jù)持久化，同時(shí)它也支持跨可用區(qū)同步，與多活場(chǎng)景比較契合。

③消息多活

我們提供了三種模式以根據(jù)不同場(chǎng)景進(jìn)行選擇：

• 各可用區(qū)的消息自產(chǎn)自銷

這個(gè)模式下Topic間不會(huì)進(jìn)行消息同步，需要生產(chǎn)端投遞本可用區(qū)的 Topic，再由本可用區(qū)的下游直接進(jìn)行消費(fèi)。這種模式比較適用于 Service至Job異步消息的場(chǎng)景，或者是ServiceA投遞給已多活的下游ServiceB這樣的情況。

• 多可用區(qū)全量消費(fèi)（Global）

這個(gè)模式下Topic間會(huì)通過(guò)Sync的一個(gè)組件雙向同步消息，每一個(gè)topic中有兩個(gè)可用區(qū)，即可用區(qū)一+可用區(qū)二的全量消息，然后同步全量消息。它適用于ServiceA投遞給未多活下游ServiceB的場(chǎng)景，比如離線或大數(shù)據(jù)，下游一般要繼續(xù)在可用區(qū)一消費(fèi)全量數(shù)據(jù)。

• 全量消費(fèi)（Global）自定義不消費(fèi)可用區(qū)

從Global模式衍生出來(lái)的一種模式，允許選擇任意一個(gè)可能區(qū)不消費(fèi)，比較適用于消息由解析Binlog觸發(fā)全量數(shù)據(jù)的情況。在可用區(qū)二的下游，需要考慮消費(fèi)后的冪等處理，包括一些存儲(chǔ)或者下游的調(diào)用放大的情況下，可選擇其中一個(gè)可用區(qū)不消費(fèi)。這個(gè)模式的好處是，出現(xiàn)可用區(qū)故障時(shí)，可通過(guò)切換消費(fèi)模式快速恢復(fù)整個(gè)消息層的消費(fèi)。

這三種模式的設(shè)置和Topic間消息同步的開啟，不會(huì)做任何綁定。在多活過(guò)程中，我們和業(yè)務(wù)共同做場(chǎng)景梳理，包括梳理明晰涉及到哪些消息隊(duì)列，哪些相關(guān)下游在確定整個(gè)消費(fèi)模式的制定等。

④數(shù)據(jù)訪問(wèn)/存儲(chǔ)層

存儲(chǔ)層同樣由我們的中間件支持，我們提供了MySQL，TiDB以及Taishan(KV)三種Proxy，整個(gè)機(jī)制沒(méi)有區(qū)別，它具備多可用區(qū)路由的能力，并且能夠具備實(shí)例拓?fù)涞淖詣?dòng)發(fā)現(xiàn)和動(dòng)態(tài)切換能力。

• GZone：對(duì)于同城雙活場(chǎng)景下數(shù)據(jù)需要全局存放的情況，即一主多從這樣的模式，服務(wù)在主可用區(qū)基本上能讀寫GZone的存儲(chǔ)，本可用區(qū)有可讀的從實(shí)例，在可用區(qū)也有從實(shí)例，通過(guò)Proxy將寫的路由回源到主機(jī)房。而在一些強(qiáng)一致的場(chǎng)景下，也提供了SQL Hint級(jí)別的配置或在連接串請(qǐng)求頭中增加一些master或者PRIMARY的配置，從而實(shí)現(xiàn)強(qiáng)制讀主的場(chǎng)景。
• RZone：在RZone單元化這一方面，業(yè)務(wù)要做數(shù)據(jù)分片，分片的數(shù)據(jù)需要完成雙向同步，本可用區(qū)的一個(gè)分片能夠?qū)崿F(xiàn)讀寫操作的封閉。
• DTS同步組件：可以實(shí)現(xiàn)數(shù)據(jù)的雙向復(fù)制，目前整體延遲小于10秒，同時(shí)支持?jǐn)?shù)據(jù)沖突檢測(cè)，發(fā)送沖突時(shí)支持暫停同步或者說(shuō)異步把通知投遞到消息隊(duì)列，再由業(yè)務(wù)來(lái)處理沖突。

二、業(yè)務(wù)多活演進(jìn)

1.多活業(yè)務(wù)劃分

在多活架構(gòu)中通常會(huì)按業(yè)務(wù)域進(jìn)行多活業(yè)務(wù)劃分，面向C端還是B端分別是兩種不同的業(yè)務(wù)形態(tài)。

2.B站的業(yè)務(wù)同城多活改造

• 單活：B站大部分業(yè)務(wù)最初也是單活模式，即服務(wù)只在單個(gè)可用區(qū)做部署，缺乏Proxy支持，緩存和DB大部分都是客戶端直連。業(yè)務(wù)發(fā)布接口需要在SLB和CDN上分別做配置，并進(jìn)行規(guī)則發(fā)布。

• 讀多活：它是一個(gè)過(guò)渡方案。雖然我們的服務(wù)開始在另一個(gè)可用區(qū)做整個(gè)部署，但在流量層面，我們只能支持讀接口的接流，而且接口大部分都通過(guò) CDN側(cè)或者SLB側(cè)進(jìn)行流量的轉(zhuǎn)發(fā)，還有一些緩存或消息隊(duì)列的一些組件未完成多活改造，存在跨機(jī)房調(diào)用的情況。

• 同城多活：我們提供了各類組件的 Proxy接入支持，使業(yè)務(wù)在可用區(qū)二能支持處理寫的請(qǐng)求，并借助Proxy支持整個(gè)容災(zāi)的自動(dòng)切換。緩存的一致性也是這個(gè)方案里的一個(gè)重點(diǎn)，要求業(yè)務(wù)必須通過(guò)Canal+Job這樣的方式維護(hù)緩存的一致性，包括消息的生產(chǎn)消費(fèi)都達(dá)成了可用區(qū)內(nèi)的閉環(huán)。

至于GZS的組件，則由Invoker平臺(tái)和APIGW對(duì)服務(wù)接口的發(fā)布進(jìn)行統(tǒng)一的管理。

我們認(rèn)為，現(xiàn)階段去做單元化改造成本較高，收益可能并不大。所以基于同城多活的方案，衍生出異地多活的架構(gòu)，目前我們正在驗(yàn)證該異地多活方案。

華南可用區(qū)是我們相對(duì)遠(yuǎn)端的一個(gè)可用區(qū)，用來(lái)承接一部分讀的流量，它整體的架構(gòu)是對(duì)標(biāo)可用區(qū)二讀多活的模式。在服務(wù)發(fā)現(xiàn)層面依舊通過(guò)Discovery的組建實(shí)現(xiàn)當(dāng)前可用區(qū)的調(diào)用，核心依賴在華南可用區(qū)完成整個(gè)部署，一些弱依賴則可返回上?？捎脜^(qū)做調(diào)用。

在數(shù)據(jù)存儲(chǔ)同步方面，原來(lái)的兩個(gè)上海可用區(qū)距離不遠(yuǎn)，我們使用的基本是一些原生的同步組件，它本身也能滿足單向同步。實(shí)現(xiàn)遠(yuǎn)端后，要繼續(xù)滿足DTS的單向同步能力。而緩存和消息隊(duì)列，則繼續(xù)遵循最終一致以及自產(chǎn)自銷的原則來(lái)實(shí)施。

三、多活管控與治理

1.多活元信息規(guī)則治理

我們初期在CDN上的一些規(guī)則偏向非標(biāo)，有大量的正則寫法，所以我們?cè)谧龅谝徊綍r(shí)就對(duì)多活元信息的規(guī)則進(jìn)行了治理，APIGW接入時(shí)也應(yīng)用了前綴路由的模式，以方便做后續(xù)的統(tǒng)一切流管理。另外，也保留了一部分非標(biāo)的多活規(guī)則，能夠提供自定義的規(guī)則錄入，例如前端或Web端的規(guī)則?；卦椿蚓彺娴囊?guī)則等非多活規(guī)則就繼續(xù)存放于CDN層面。

2.Invoker平臺(tái)多活&強(qiáng)依賴降級(jí)&演練

Invoker平臺(tái)也有一些依賴，我們將其中的業(yè)務(wù)資源元信息存放在CMDB中，還有一些存放登錄態(tài)、鑒權(quán)和工單審批的系統(tǒng)。我們?cè)诮ㄔO(shè)Invoker的同時(shí)，對(duì)這個(gè)平臺(tái)做了GZone模式的部署。我們對(duì)它的核心依賴都做了故障演練，對(duì)每一個(gè)依賴也做了降級(jí)方案。之前也遇到過(guò)管理后臺(tái)在故障時(shí)無(wú)法登錄的情況，所以留了超管權(quán)限，并做了異地部署，以保證Invoker平臺(tái)在故障時(shí)可用。

3.多活流量管控

在多活編排接入流程化這一方面，基于跟業(yè)務(wù)做改造和做接入的經(jīng)驗(yàn)，總結(jié)了一些方法論，完成了平臺(tái)化和功能化。

1)編排、預(yù)檢與觀測(cè)

做業(yè)務(wù)接入時(shí)，首先要對(duì)多活業(yè)務(wù)進(jìn)行定義，由此平臺(tái)側(cè)能讓我們基于CMDB選擇業(yè)務(wù)，定義它的多活類型，從而編排整個(gè)接入層的切量規(guī)則和數(shù)據(jù)層的切量規(guī)則。目前我們支持消息層的切換和東西流量的編排。在進(jìn)行日常的切量演練或故障演練前，我們會(huì)做前置的檢查，例如容量巡檢、sos層面的監(jiān)控、數(shù)據(jù)庫(kù)的連接池、業(yè)務(wù)在SLB平臺(tái)的限流配置等，要提前檢查其狀態(tài)，并預(yù)檢DB和KV主從同步的延遲情況。

2)切量

在切量的過(guò)程中，我們會(huì)觀測(cè)業(yè)務(wù)多活流量的變化與新引入的SLO體系的相關(guān)指標(biāo)。在這個(gè)平臺(tái)做了集成后，最后一個(gè)環(huán)節(jié)則是將多活驗(yàn)證的思路落實(shí)到平臺(tái)，例如要求多活流量在單可用區(qū)內(nèi)做到閉環(huán)，而針對(duì)一些弱依賴則要求業(yè)務(wù)去做故障演練。

4.多活定義編排

多活定義編排是指，能夠選擇一個(gè)業(yè)務(wù)去定義它的多活模式，確定它是CZone、GZone還是RZone的方式，確定它的服務(wù)具體分布的地域位置和可用區(qū)。

在接入層，除了有APIGW比較標(biāo)準(zhǔn)的一些前置規(guī)則，也支持自定義規(guī)則的錄入，以及它在DCDN層面流量調(diào)度的比例。

我們?cè)跀?shù)據(jù)層面支持Taishan(KV)和DB的編排錄入，包括下游的消費(fèi)任務(wù)，如Canal或 KV的同步任務(wù)這一部分的切換。

上圖是執(zhí)行切量過(guò)程的界面，在切量申請(qǐng)時(shí)會(huì)選擇一個(gè)業(yè)務(wù)，然后選擇它的一個(gè)切流緯度，包括它要求的切流比例，選擇是否同時(shí)去切換我們的存儲(chǔ)，執(zhí)行切流是切哪些規(guī)則，對(duì)切量對(duì)象選擇進(jìn)行配置。

5.切流預(yù)檢與可視化

以往由人工完成的這一流程，如今被整合到平臺(tái)中，支持容量延遲和限流的預(yù)檢。在切流過(guò)程中，我們能觀測(cè)服務(wù)、緩存和DB等容量情況。

目前在做的一些接入如SLO觀測(cè)則包括鏈路的依賴、整體鏈路上下游的SLO情況等，我們也在做平臺(tái)側(cè)的接入。

6.多活有效性驗(yàn)證

1)依賴展示

同城多活方案強(qiáng)調(diào)在機(jī)房?jī)?nèi)能夠?qū)崿F(xiàn)讀寫流量的處理，以便在故障時(shí)快速恢復(fù)。因此在有效性驗(yàn)證方面，比較注重依賴的排查。我們能在平臺(tái)側(cè)展示依賴，同時(shí)能展示服務(wù)的下游依賴和組件依賴，這方面用到了Trace的能力。

2)依賴檢查

針對(duì)需要確定哪些依賴是強(qiáng)依賴，哪些依賴是弱依賴的類似情況，我們會(huì)對(duì)依賴進(jìn)行檢查和打標(biāo)。

3)流量閉環(huán)

打標(biāo)后，會(huì)進(jìn)行流量閉環(huán)的檢查，通過(guò)打標(biāo)和依賴發(fā)現(xiàn)這些信息，然后進(jìn)行跨可用區(qū)調(diào)用的發(fā)現(xiàn)，直到確認(rèn)核心依賴在可用區(qū)內(nèi)是閉環(huán)的，弱依賴則要求業(yè)務(wù)排期做演練。

4)故障演練

這部分由框架SDK支持，它能夠?qū)崿F(xiàn)依賴的自動(dòng)發(fā)現(xiàn)和自動(dòng)的故障演練，最終會(huì)輸出一份報(bào)告，確認(rèn)是否都符合預(yù)期。若與預(yù)期不符，再進(jìn)行改造和演練。

Q&A

Q1：同城雙活架構(gòu)下應(yīng)用層做了雙多活，基礎(chǔ)架構(gòu)層還有必要雙活嗎？

A1：我覺得有必要。所有的技術(shù)組件在設(shè)計(jì)時(shí)就要考慮雙活模式，因?yàn)闃I(yè)務(wù)的多活基于組建本身的高可用，如之前介紹的Invoker組件的多活，它對(duì)于鑒權(quán)工單審批的依賴，我們都需要去考慮它的多活設(shè)計(jì)，以及在真正出現(xiàn)單可用區(qū)故障的時(shí)刻，我如何能登錄這個(gè)平臺(tái)去實(shí)現(xiàn)多活管控。

Q2：多活如何保證數(shù)據(jù)一致性？

A2：這還需要根據(jù)數(shù)據(jù)中心的分布和業(yè)務(wù)形態(tài)來(lái)進(jìn)行方案的選擇。若是同城，只要考慮寫主庫(kù)讀從庫(kù)的模式，強(qiáng)一致性的需要強(qiáng)制讀寫主庫(kù)。若是比較遠(yuǎn)距離異地多活，需要進(jìn)行數(shù)據(jù)分片、單元化雙寫的改造，并且能夠接受部分?jǐn)?shù)據(jù)的同步延遲，因?yàn)榭绲赜虻暮臅r(shí)增加屬于物理層面，無(wú)法避免。只能根據(jù)一個(gè)合適的業(yè)務(wù)場(chǎng)景，適配相應(yīng)的多活方案。關(guān)于緩存數(shù)據(jù)，前面也介紹了緩存一致性的幾種維護(hù)方式。

Q3：高可用多活的成本如何把控，過(guò)程中對(duì)ROI的考慮是怎樣的？

A3：要從以下兩個(gè)方面分析：一是收益。發(fā)生故障時(shí)，就會(huì)感知到多活的收益是有價(jià)值的。B站在21年經(jīng)歷過(guò)一次比較大的故障，當(dāng)時(shí)恢復(fù)最快的原因是已經(jīng)做了多活的業(yè)務(wù)，哪怕是只做了讀多活的一些業(yè)務(wù)，也恢復(fù)得很快?？赡芤?yàn)锽站讀場(chǎng)景比較多，所以對(duì)用戶感知層面讀場(chǎng)景的快速恢復(fù)能大大緩解用戶側(cè)的焦慮和客戶投訴的情況；

二是成本。一是注意資源增長(zhǎng)，因?yàn)楝F(xiàn)在做的都是同城多活模式，同城的機(jī)房服務(wù)都是在線提供，所以它不存在資源的空好浪費(fèi)。日常我們也會(huì)準(zhǔn)備一些資源冗余來(lái)應(yīng)對(duì)突發(fā)情況和高峰期，即換個(gè)思路，可以通過(guò)資源的彈性或混部來(lái)進(jìn)行運(yùn)維成本的增加。如Invoker平臺(tái)，它就是大大降低運(yùn)維成本增加的工具，它能把一些人工完成的事情都轉(zhuǎn)化為平臺(tái)的功能層面，出現(xiàn)故障時(shí)能夠一鍵執(zhí)行切流。所以要把收益和成本兩件事結(jié)合考慮。