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

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

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

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

2.多活的方案類型

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

• GZone模式

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

• RZone模式

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

• CZone模式

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

B站具有多個數(shù)據(jù)中心，但整體定位比較混亂，所以我們在多活場景里重新做了梳理和劃分。

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

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

1)同城多活

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

2）異地多活

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

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

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

3） B站的同城多活

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

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

①流量接入層

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

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

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

APIGW本身是一個容器部署的服務(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降級、熔斷和限流，包括我們和客戶端聯(lián)動的流控能力，避免服務(wù)故障時客戶端瘋狂重試導(dǎo)致進(jìn)一步壓垮服務(wù)。

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

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

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

②緩存一致性

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

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

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

• 純緩存場景

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

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

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

• 分布式鎖場景

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

③消息多活

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

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

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

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

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

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

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

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

④數(shù)據(jù)訪問/存儲層

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

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

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

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

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

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

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

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

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

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

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

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

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

三、多活管控與治理

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

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

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

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

3.多活流量管控

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

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

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

2)切量

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

4.多活定義編排

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

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

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

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

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

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

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

6.多活有效性驗證

1)依賴展示

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

2)依賴檢查

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

3)流量閉環(huán)

打標(biāo)后，會進(jìn)行流量閉環(huán)的檢查，通過打標(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)依賴的自動發(fā)現(xiàn)和自動的故障演練，最終會輸出一份報告，確認(rèn)是否都符合預(yù)期。若與預(yù)期不符，再進(jìn)行改造和演練。

Q&A

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

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

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

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

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

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

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