1、背景

2024 年 7 月 2 日 10:04，我站機房 A 公網(wǎng)物理光纜中斷，導(dǎo)致機房 A 公網(wǎng)無法訪問。本文將從 DCDN 架構(gòu)及多活治理的視角，分析本次故障中我們發(fā)現(xiàn)的問題和治理優(yōu)化措施。

2、止損過程

故障發(fā)生后，SRE與網(wǎng)工接收到大量專線中斷、公網(wǎng)探測告警，快速拉起線上會議協(xié)同進(jìn)行故障定位及止損操作；

在此期間核心業(yè)務(wù)（如首頁推薦、播放等）因在 DCDN 側(cè)配置了源站機房級別自動容災(zāi)生效，未受影響；

首先定位到的是單個運營商線路存在大量丟包異常，優(yōu)先將該運營商用戶流量切向具有專線回源的 CDN 專線節(jié)點，此時這部分用戶流量恢復(fù)，但整體業(yè)務(wù)未完全恢復(fù)；

繼續(xù)定位到整個機房 A 公網(wǎng)完全無法訪問，而從機房 B 核心業(yè)務(wù)場景因自動容災(zāi)生效存在流量上升且觀測業(yè)務(wù) SLO 正常，決策執(zhí)行全站多活業(yè)務(wù)切流至機房 B 止損。此時多活業(yè)務(wù)完成止損，非多活業(yè)務(wù)仍有損；

繼續(xù)對非多活業(yè)務(wù)流量執(zhí)行降級，將用戶流量切向 CDN 專線節(jié)點回源，此時非多活業(yè)務(wù)流量完成止損。

3、問題分析

圖1：南北向流量架構(gòu)圖 / 0702故障邏輯圖

圖2：B2-CDN環(huán)網(wǎng)示意圖

先簡單介紹一下 B 站源站架構(gòu)，從上圖1可以看出，B 站在線業(yè)務(wù)有兩個核心機房，每個機房都有兩個互聯(lián)網(wǎng)接入點（公網(wǎng) POP ），且這兩個互聯(lián)網(wǎng)接入點分布在不同的省市。這樣設(shè)計的核心思路：網(wǎng)絡(luò)接入（以下統(tǒng)稱為 POP ）和算力中心（以下統(tǒng)稱為機房）解耦，達(dá)到接入層故障可容災(zāi)的效果。

同時從圖2可知，為了提升自建 CDN 節(jié)點到源站核心機房的回源穩(wěn)定性和效率。我們完成了 B2-CDN 環(huán)網(wǎng)的設(shè)計和建設(shè)，實現(xiàn)了從邊緣 L1 & L2 自建 CDN 節(jié)點通過該環(huán)網(wǎng)進(jìn)行回源，豐富了業(yè)務(wù)從邊緣節(jié)點回核心源站獲取數(shù)據(jù)的途徑。其實 B2-CDN 環(huán)網(wǎng)的設(shè)計初衷是為了給各 L1 & L2 自建CDN節(jié)點在處理邊緣冷流、溫流、熱流時能有更多的手段，以探索更加適合有 B 站業(yè)務(wù)特征的邊緣網(wǎng)絡(luò)調(diào)度方式。B2-CDN 環(huán)網(wǎng)底層通過二層 MPLS-VPN 技術(shù)實現(xiàn)各節(jié)點 Full-Mesh，并在此基礎(chǔ)上通過三層路由協(xié)議（OSPF、BGP） 實現(xiàn)各節(jié)點與源站核心機房之間的互聯(lián)互通。同時各業(yè)務(wù)保留通過公網(wǎng)回源核心機房的能力，做為 B2-CDN 環(huán)網(wǎng)出現(xiàn)極端故障情況下的兜底回源方案。

B 站接口類請求主要通過 DCDN 加速回到源站，DCDN 節(jié)點分為兩種類型，通過公網(wǎng)回源的公網(wǎng)節(jié)點和通過專線回源的專線節(jié)點。正常情況下 DCDN 公網(wǎng)節(jié)點可通過雙公網(wǎng) POP 回到源站，DCDN 專線節(jié)點則通過內(nèi)網(wǎng)專線回到源站。并且在 DCDN 層面，有針對源站的 Health Check 功能，會自動摘除探測異常的源站 IP。比如當(dāng) DCDN 節(jié)點請求回源 POP A 發(fā)生異常時，會重試到 POP B。DCDN 公網(wǎng)節(jié)點常態(tài)可通過雙 POP 交叉回源站，應(yīng)對 DCDN 到某一個源站 POP 點出現(xiàn)丟包或中斷，容災(zāi)方案自動生效，對業(yè)務(wù)幾乎無影響。

然而本次故障中雙 POP 至機房 A 故障，相當(dāng)于機房 A 公網(wǎng)脫網(wǎng)。不同于單 POP 故障，常規(guī)雙 POP 之間互相容災(zāi)方案無法生效。除了幾個核心業(yè)務(wù)場景因前置配置了機房級別的故障容災(zāi)策略未受影響外，非自動容災(zāi)的多活業(yè)務(wù)需要執(zhí)行機房維度切流進(jìn)行止損。由于DCDN 專線節(jié)點可以通過 B2-CDN 環(huán)網(wǎng)專線回源不受本次故障影響，最終成為了非多活業(yè)務(wù)的逃生通道。

回顧整個止損過程，我們發(fā)現(xiàn)了以下問題：

• 機房極端斷網(wǎng)故障，定界較慢且預(yù)案不夠完備
• 部分多活的業(yè)務(wù)仍需要手動切流止損，是否可以更快速，甚至自動止損
• 非多活的業(yè)務(wù)應(yīng)對機房出入口故障，如何主動逃生

4、優(yōu)化措施

針對本次故障中遇到問題，我們重新評估了單機房故障的預(yù)案及改進(jìn)措施，可以看到多活業(yè)務(wù)整體的止損預(yù)案是一致的，重點關(guān)注自動容災(zāi)生效及手動切流的效率；而非多活的業(yè)務(wù)需要有多種逃生手段：通過DCDN內(nèi)網(wǎng)節(jié)點回源、或通過API網(wǎng)關(guān)跨機房轉(zhuǎn)發(fā)。

機房極端網(wǎng)絡(luò)故障預(yù)案

如上文所述，源站有雙公網(wǎng)POP加專線三個入口，所以邏輯上任意兩個入口異常，都依然有機會保證業(yè)務(wù)可用性。因此我們做了如下措施：

• 對 DCDN 專線節(jié)點算力及規(guī)模擴容，盡力提升極端情況下的承載能力；
• 雙公網(wǎng) POP 出口異常情況下的調(diào)度預(yù)案，對域名和DCDN節(jié)點類型進(jìn)行分組，支持非多活域名快速切到專線節(jié)點；由于多活域名可通過切流止損，為了不額外增加專線節(jié)點負(fù)載，不需要調(diào)度至專線節(jié)點；
• 故障的定界效率提升，對重要監(jiān)控的上報鏈路進(jìn)行優(yōu)化，與業(yè)務(wù)鏈路解耦，并且在公有云進(jìn)行了容災(zāi)部署；同時優(yōu)化網(wǎng)絡(luò)拓?fù)涿姘澹逦故久織l鏈路的情況；以及告警和展示方式，方便快速定位問題。

圖3：DCDN流量調(diào)度架構(gòu)：日常態(tài) / 容災(zāi)態(tài)

多活建設(shè)持續(xù)推進(jìn)及常態(tài)化演練

圖4：同城多活架構(gòu)簡圖

當(dāng)前我站業(yè)務(wù)主要為同城多活架構(gòu)，如圖4所示，我們將多個機房邏輯上劃分為兩個可用區(qū)，每個可用區(qū)日常承擔(dān)50%的流量，將整體多活架構(gòu)分層來看：

• 接入層：
• DCDN：南北向流量管控，基于用戶緯度信息Hash路由至不同可用區(qū)的源站機房，支持可用區(qū)維度自動容災(zāi)；
• 七層負(fù)載/API網(wǎng)關(guān)：南北向流量管控，支持接口級別路由、超時控制、同/跨可用區(qū)重試、熔斷、限流&客戶端流控等；
• 服務(wù)發(fā)現(xiàn)/服務(wù)治理組件：東西向精細(xì)流量管控，框架 SDK 支持同可用區(qū)內(nèi)優(yōu)先調(diào)用，服務(wù)、接口級別流量調(diào)度；
• 緩存層：主要為 Redis Cluster、Memcache，提供 Proxy 組件供接入，不支持跨可用區(qū)同步，需雙可用區(qū)獨立部署；通過訂閱數(shù)據(jù)庫Binlog維護(hù)數(shù)據(jù)最終一致性，同時對于純緩存場景需要改造；
• 消息層：原則上可用區(qū)內(nèi)封閉生產(chǎn)/消費，支持 Topic 級別消息跨可用區(qū)雙向同步，Local/Global/None 三種消費模式適配不同業(yè)務(wù)場景；
• 數(shù)據(jù)層：主要為 MySQL、KV 存儲，主從同步模式；提供 Proxy 組件供業(yè)務(wù)接入，支持多可用區(qū)可讀、就近讀、寫流量路由至主、強制讀主等；
• 管控層：Invoker 多活管控平臺，支持多活元信息管理、南北向/東西向切流、DNS 切換、預(yù)案管理、多活風(fēng)險巡檢；

對于完成多活改造的業(yè)務(wù)，我們建設(shè)了多活管控平臺對業(yè)務(wù)多活元信息進(jìn)行統(tǒng)一維護(hù)，支持業(yè)務(wù)南北向及東西向多活切流管控。平臺側(cè)支持切流預(yù)案的維護(hù)，支持單業(yè)務(wù)、多業(yè)務(wù)、全站維護(hù)的快速切流。同時平臺提供多活相關(guān)風(fēng)險巡檢能力，從多活流量比、業(yè)務(wù)容量、組件配置、跨機房調(diào)用等角度常態(tài)巡檢風(fēng)險，支持相關(guān)風(fēng)險的治理運營。

前置完成進(jìn)行預(yù)案維護(hù)和風(fēng)險治理后，我們定期進(jìn)行單個業(yè)務(wù)、多個業(yè)務(wù)組合南北向切流演練，驗證服務(wù)自身、其依賴組件、其依賴下游的容量、限流等資源負(fù)載情況，常態(tài)保證多活的有效性，常態(tài)可切換可容災(zāi)。

機房級別自動容災(zāi)

對于用戶強感知的場景涉及的核心服務(wù)，在DCDN側(cè)配置源站機房級別的容災(zāi)策略，應(yīng)對單個源站機房入口故障時可以自動將流量路由至另一個機房實現(xiàn)止損。

多活業(yè)務(wù)的自動容災(zāi)原先沒有默認(rèn)全配置，優(yōu)先保障了首頁推薦、播放相關(guān)等主場景，其余業(yè)務(wù)場景根據(jù)資源池水位情況執(zhí)行切流。當(dāng)前我們資源池平均CPU利用率已達(dá)35%+，在線業(yè)務(wù)平均峰值CPU利用率接近50%，我們已經(jīng)對全站業(yè)務(wù)切流單機房的資源需求進(jìn)行梳理，同時多活切流也將聯(lián)動平臺進(jìn)行HPA策略調(diào)整，以及準(zhǔn)備資源池的快速彈性預(yù)案，確保大盤資源的健康。后續(xù)將支持對社區(qū)互動、搜索、空間等更多用戶強感知場景自動容災(zāi)策略配置。在遇到機房級別故障時候無需人工干預(yù)，多活業(yè)務(wù)可直接容災(zāi)止損。

圖5：多活業(yè)務(wù)南北向流量架構(gòu)：日常態(tài) / 容災(zāi)態(tài)

非多活流量逃生

部分業(yè)務(wù)當(dāng)前是沒有多機房多活部署的，僅在一個機房可以處理流量；因此在原來的方案中，這部分非多活業(yè)務(wù)流量只會回源至機房 A，無法應(yīng)對機房 A 公網(wǎng)入口故障。如同本次事故中，非多活業(yè)務(wù)流量無法切流止損，依賴降級走CDN專線節(jié)點。

為了應(yīng)對單機房公網(wǎng)入口、四層負(fù)載、七層負(fù)載故障等場景，我們計劃在DCDN側(cè)為非多活業(yè)務(wù)規(guī)則也配置源站級別自動容災(zāi)，在七層負(fù)載SLB實現(xiàn)多機房多集群的路由配置合并統(tǒng)一，確保非多活業(yè)務(wù)的流量在故障時可進(jìn)入機房 B 路由至API網(wǎng)關(guān)；在API網(wǎng)關(guān)側(cè)判斷接口是否多活，非多活接口通過內(nèi)網(wǎng)專線進(jìn)行流量轉(zhuǎn)發(fā)，實現(xiàn)流量逃生。

圖6：非多活業(yè)務(wù)南北向流量架構(gòu)：日常態(tài) / 容災(zāi)態(tài)

5、總結(jié)

單個機房級別的故障，非?？简灦嗷罡脑斓耐暾院陀行?，同時必須需要故障演練來進(jìn)行驗證，下半年我們會繼續(xù)重點關(guān)注多活風(fēng)險治理，除了常態(tài)的切流演練外也會啟動南北向、東西向的斷網(wǎng)演練。