1、背景

2024 年 7 月 2 日 10:04，我站機房 A 公網物理光纜中斷，導致機房 A 公網無法訪問。本文將從 DCDN 架構及多活治理的視角，分析本次故障中我們發現的問題和治理優化措施。

2、止損過程

故障發生后，SRE與網工接收到大量專線中斷、公網探測告警，快速拉起線上會議協同進行故障定位及止損操作；

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

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

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

繼續對非多活業務流量執行降級，將用戶流量切向 CDN 專線節點回源，此時非多活業務流量完成止損。

3、問題分析

圖1：南北向流量架構圖 / 0702故障邏輯圖

圖2：B2-CDN環網示意圖

先簡單介紹一下 B 站源站架構，從上圖1可以看出，B 站在線業務有兩個核心機房，每個機房都有兩個互聯網接入點（公網 POP ），且這兩個互聯網接入點分布在不同的省市。這樣設計的核心思路：網絡接入（以下統稱為 POP ）和算力中心（以下統稱為機房）解耦，達到接入層故障可容災的效果。

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

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

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

回顧整個止損過程，我們發現了以下問題：

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

4、優化措施

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

機房極端網絡故障預案

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

• 對 DCDN 專線節點算力及規模擴容，盡力提升極端情況下的承載能力；
• 雙公網 POP 出口異常情況下的調度預案，對域名和DCDN節點類型進行分組，支持非多活域名快速切到專線節點；由于多活域名可通過切流止損，為了不額外增加專線節點負載，不需要調度至專線節點；
• 故障的定界效率提升，對重要監控的上報鏈路進行優化，與業務鏈路解耦，并且在公有云進行了容災部署；同時優化網絡拓撲面板，清晰展示每條鏈路的情況；以及告警和展示方式，方便快速定位問題。

圖3：DCDN流量調度架構：日常態 / 容災態

多活建設持續推進及常態化演練

圖4：同城多活架構簡圖

當前我站業務主要為同城多活架構，如圖4所示，我們將多個機房邏輯上劃分為兩個可用區，每個可用區日常承擔50%的流量，將整體多活架構分層來看：

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

對于完成多活改造的業務，我們建設了多活管控平臺對業務多活元信息進行統一維護，支持業務南北向及東西向多活切流管控。平臺側支持切流預案的維護，支持單業務、多業務、全站維護的快速切流。同時平臺提供多活相關風險巡檢能力，從多活流量比、業務容量、組件配置、跨機房調用等角度常態巡檢風險，支持相關風險的治理運營。

前置完成進行預案維護和風險治理后，我們定期進行單個業務、多個業務組合南北向切流演練，驗證服務自身、其依賴組件、其依賴下游的容量、限流等資源負載情況，常態保證多活的有效性，常態可切換可容災。

機房級別自動容災

對于用戶強感知的場景涉及的核心服務，在DCDN側配置源站機房級別的容災策略，應對單個源站機房入口故障時可以自動將流量路由至另一個機房實現止損。

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

圖5：多活業務南北向流量架構：日常態 / 容災態

非多活流量逃生

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

為了應對單機房公網入口、四層負載、七層負載故障等場景，我們計劃在DCDN側為非多活業務規則也配置源站級別自動容災，在七層負載SLB實現多機房多集群的路由配置合并統一，確保非多活業務的流量在故障時可進入機房 B 路由至API網關；在API網關側判斷接口是否多活，非多活接口通過內網專線進行流量轉發，實現流量逃生。

圖6：非多活業務南北向流量架構：日常態 / 容災態

5、總結

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