B站公網架構實踐及演進
01 引言
根據2022年Q3財報資料,B站的MAU已經穩定增長至3.3億。使用者在閒暇之餘刷刷影片、看看直播,給自己喜愛的UP主一鍵三連,已經成為了生活中不可缺少的一部分。B站基礎網路團隊本著社群優先的理念,持續最佳化網際網路接入網路架構,近2年內根據IDC規模發展和業務需求,對公網架構進行了有序升級改造,從穩定性、經濟性等方面為B站業務提供了堅實保障。
02 B站公網1.0結構
在B站IDC公網1.0結構中,每個機房有獨立的靜態頻寬線路,部分重要業務基於延遲要求配置BGP頻寬提供服務。網路結構如圖1所示:
圖1 B站IDC公網1.0結構
B站公網1.0結構中,核心網路裝置相當於整個網路樞紐,最大化的利用了核心網路裝置硬體資源和轉發能力。公網出口線路直連本機房核心網路裝置,同時核心網路裝置旁掛LB、NAT等基礎元件,另外下掛機房內DCN網路。
控制層面:兩臺核心網路裝置採用堆疊技術虛擬成一臺。在提升單臺裝置硬體接入能力的同時,降低了整體運維成本。
線路資源:各家運營商資源至少冗餘鏈路接入,提供靜態頻寬和BGP頻寬接入,保證公網出口冗餘能力。
服務元件:機房內LB(Load Balance)、NAT(Network Address Transfer)等基礎閘道器服務採用One-Arm的方式旁掛核心網路裝置,主動提供對外、對內的Internet服務訪問能力。
路由策略:由於核心網路裝置在網路中的角色特殊性,對於特定流量需要做特定的路由策略,才能進行正確轉發,如:公網流量需要透過技術手段將流量先引入LB,再轉發到機房內特定伺服器。
該架構組網簡單,涉及裝置較少、網路層面配置簡單,但是隨著B站的業務發展,在長期的運維過程中,我們也發現了幾個值得仔細考慮的問題。
問題一:網路故障域
在B站公網1.0的網路結構中,核心網路裝置在網路中承擔的角色非常重,所有流量都要經過核心裝置轉發,這就造成核心網路裝置上任何一個故障,都會有較大的影響。比如單個埠器件異常,有可能會影響到公網和內網服務。長此以往網路運維將面臨巨大挑戰,該問題也成為了B站網路團隊需要重點解決的問題之一。
問題二:網路可靠性
在B站1.0公網架構中,每個IDC都會引入靜態三線頻寬和BGP頻寬。公網出口的可用性與運營商網路強耦合,更多依賴運營商公網的穩定性。當運營商公網出現故障時,網路上缺乏主動隔離故障的手段和能力,從而導致業務受損。處理方式上只能主動告知業務進行線路切換,緩解由運營商網路故障的帶來的異常影響。
問題三:網路擴充套件性
B站公網出口以靜態頻寬為主,BGP頻寬為輔。靜態頻寬資源基本上被運營商強繫結,擴容週期長且流程繁瑣,甚至部分地區受運營商網路影響,擴容存在一定困難。結合B站業務的特殊性,在重大活動期間需要具備公網大頻寬能力,如果運營商頻寬資源準備不足,B站將會面臨業務損。網路上需要考慮臨時應急方案,直接後果是因擴充套件性問題增加了網路的複雜性。
問題四:網路資源
眾所周知,全球公網IPV4地址資源日漸缺乏,且公網IP地址與運營商及機房有一定的強捆綁性,部分機房申請公網IPV4地址困難,面臨沒有公網IPV4地址問題。頻寬利用率方面,由於B站各個機房部署的業務不同,出入頻寬模型有所差異,不同機房公網頻寬利用率差別較大,無法充分利用各個機房公網頻寬資源。
問題五:頻寬成本
每個IDC出口同時提供靜態頻寬和BGP頻寬能力,當新建核心機房時,都需要尋找合適的公網資源並對資源進行評估及測試,整個過程複雜且週期長。不同地區的公網頻寬相互隔離,Buffer都需要單獨預留,造成了浪費;同時因為沒有相互排程的能力,為了保證業務質量,所以使用了大量的BGP頻寬資源。然而此舉不可持續,隨著業務的發展,BGP頻寬量每年持續增長,會導致BGP的頻寬成本持續增加。
問題六:容災能力
IDC日常使用中,任何一個機房的公網出口都有可能出現異常情況。當公網出口發生故障時,以同城雙活業務部署為例,業務按降級預案進行切換,從A機房降級到B機房,在底層頻寬資源上A和B兩個機房需要按照降級預案准備同等容量的公網頻寬,以達到A/B兩個機房之間公網冗餘能力,從而保證業務不受影響。然而當發生地域性級別的公網故障時(如:某運營商某個省骨幹網異常),同城雙活方案將失效,因此業務還需要考慮異地容災降級方案,這樣會使業務的整體容災能力變得非常複雜。
03 B站公網2.0結構
為了解決公網1.0結構中存在的問題,2020底B站基礎網路團隊調研了國內外網際網路頭部公司的網路架構,開始重新設計機房整體網路結構,包括DCN內網、DCI骨幹網、外網、基礎服務網路。重點從如下幾個方面因素進行最佳化設計。
網路區域化:網路按功能區劃分,各功能區域劃清界限,職責清晰;
SLA差異化:不同的網路模組按不同的SLA要求設計,滿足不同業務的需求;
資源集中化:新建區域級公網POP節點,對外接入不同公網頻寬資源,對內統一接入,為各機房提供公網服務能力;
硬體差異化:基於不同的網路需求,配置不同的硬體,比如公網更多關注路由能力,考慮使用路由器;內網更多關注頻寬能力,考慮使用交換機;
基於以上因素考慮,B站基礎網路團隊設計了B站公網2.0結構,包含B站外網骨幹網2.0結構和IDC公網2.0結構,分別如下圖2和圖3所示:
圖2 B站外網骨幹網2.0結構
B站外網骨幹網2.0結構說明
B站外網骨幹網做為底層承載網,為業務提供公網接入能力,實現對使用者接入;
B站外網骨幹網採用路由器裝置,同時具備高效能轉發和故障快速收斂能力;
單區域至少部署雙POP節點,每個POP節點接入不同的付費公網頻寬資源,免費頻寬資源;
對內統一接入,將公網頻寬資源下發到各個機房,提升公網頻寬利用率的同時保障公網容災能力;
減少人力成本投入,新建IDC可以共用外網骨幹網頻寬資源,無需再走一遍重複的接入流程;
各機房集中資源接入,規模效應能夠具備更優的談判條件,從而獲取更優質更經濟的公網資源;
由於接入了異地資源,能夠實現單個機房公網出口跨地域級的容災能力,大大簡化業務的多活架構;
降低公網故障頻寬和降級預案複雜度,僅需DNS將業務排程至本機房的另一套公網資源即可;
圖3 B站IDC公網2.0結構
B站IDC公網2.0結構說明
每個機房內部存在獨立的外網區域,並可根據業務需求靈活擴充套件;
外網核心(E-CORE)與公網元件(LB/NAT)組成機房的外網區;
組網完全去堆疊化,每個層級的裝置均獨立執行,控制層面完全獨立;
每個機房上聯外網骨幹網,提供靜態頻寬和BGP頻寬資源以及免費頻寬資源;
加強公網安全能力建設,SGW(Security GateWay)旁掛於外網核心,用於檢測公網異常流量;
LB/NAT採用Two-Arm的方式串聯在外網與內網之間,起到內外網隔離的作用,降低網路運維複雜度;
LB以叢集的方式對外提供服務,保障服務高可用,不同的LB機器釋出相同的公網地址,為業務提供服務;
NAT與內網核心(I-CORE)建立BGP鄰居併發布預設路由至DCN網路,為機房伺服器提供Internet服務;
B站公網2.0結構,經過半年建設、半年灰度驗證,在業務部門的配合下,2022年初專案已完成上線,各IDC機房公網業務平穩完成遷移並穩定執行至今。
04 外網骨幹網擴充套件
CDN網路
一個影片網站要為使用者提供服務就避不開CDN與源站。海量影片檔案需要從儲存系統分發到使用者終端,為了縮短B站與使用者端的距離,提升使用者體驗,B站儘可能的在全國甚至全球部署CDN網路,以達到就近覆蓋使用者的目的。一般單個CDN節點規模小,儲存、算力均有限,所以B站會在全國範圍內部署多個大容量的區域級快取CDN節點提供服務能力。B站影片業務資料分發儲存與地址位置關係大致如下圖4:
圖4 影片業務資料分發及儲存示意圖
CDN/邊緣節點:規模小,提供算力、資料儲存能力有限,就近為使用者提供服務,業務利用相對少量的計算和儲存資源快取熱門資料,並且會根據使用者觀看偏好等行為進行快取內容的及時更新調整;
區域級骨幹節點:規模適中,區域性集中的算力和資料儲存,作為邊緣節點的容量溢位以及故障備份,也可說為二級緩節點,同時也對使用者提供服務;
核心IDC:即源站IDC機房,規模大,承擔整個公司的規模化算力和資料儲存,具有B站所有服務資源。
CDN回源
早期B站CDN均是採用公網回源的方案,該方案實現簡單,對公網強依賴,有鏈路不穩定的風險,公網頻寬佔用較大,成本較高。示意圖如下圖5:
圖5 B站早期影片播放鏈路簡易示圖
中期為了降低公網頻寬成本,業務採用CDN分級部署方案,一級節點就近公網回源二級節點,減少了公網鏈路長度,有效提升了回源的穩定性。示意圖如下圖6:
圖6 B站中期影片播放鏈路簡易示圖
後期為了規避公網波動對回源的影響,進一步降低公網回源頻寬成本,對於部分CDN節點,建設專線用於業務回源。結構如下圖7:
圖7 B站後期影片播放鏈路簡易示圖
從外向內共分為5級,連線關係、接入方式如下:
CDN節點單規/雙規就近接入都會網路節點,優先透過專線網路回源,公網回源則作為兜底策略;
都會網路節點就近單規/雙規上聯至區域級骨幹網節點,接入方式取決於物理位置及成本考量;
骨幹網節點就近接入B站POP節點,透過POP節點打通CDN與源站網路;
總體來說,CDN節點做為B站外網骨幹網的擴充套件網路,在有限的資源和成本下,提供了更穩定的網路服務,為B站使用者提供了更優的衝浪體驗。
05 未來展望
B站基礎網路團隊從穩定、成本、效率出發,以持續最佳化使用者體驗為目標,將使用者始終放在第一位。依託運營商資源逐步最佳化公網服務,減少上層業務及使用者對網路異常的感知。下一步我們將加快B站外網骨幹網的覆蓋範圍,加強跨大區級的公網排程能力。同時結合業務發展需求與行業內發展趨勢,最佳化公網部分元件及探索更前沿的技術,為B站提供更穩定、更高效、更低成本的網路服務。
來自 “ 嗶哩嗶哩技術 ”, 原文作者:系統部網路團隊;原文連結:http://server.it168.com/a2022/1216/6781/000006781040.shtml,如有侵權,請聯絡管理員刪除。
相關文章
- Serverless 架構演進與實踐Server架構
- 荔枝架構實踐與演進歷程架構
- Serverless 架構模式及演進Server架構模式
- 【AliFlutter】Flutter Fish Redux 2.0 架構演進實踐FlutterRedux架構
- 51信用卡 Android 架構演進實踐Android架構
- 美團配送系統架構演進實踐架構
- B站故障演練平臺實踐
- 技術架構分享:美團配送系統架構演進實踐架構
- 美團實時數倉架構演進與建設實踐架構
- 林意群:eBay HDFS架構的演進優化實踐架構優化
- 智慧安全3.0實踐|SASE技術架構的演進之路架構
- B站基於Iceberg的湖倉一體架構實踐架構
- 汽車之家10年系統架構演進與平臺化架構實踐架構
- 大型網站架構演進的五大階段盤點網站架構
- 前端⼤規模構建演進實踐前端
- 架構演進之「微服務架構」架構微服務
- 網商銀行×SOFAStack:首家雲上銀行的微服務架構實踐與演進AST微服務架構
- 大神講解微服務治理的技術演進和架構實踐微服務架構
- B站萬億級資料庫選型與架構設計實踐資料庫架構
- Airbnb的架構演進AI架構
- Serverless 架構的演進Server架構
- 聊聊演進式架構架構
- 銀行業信創架構設計規劃及實踐 | 架構進階行業架構
- WebRTC 架構優化及實踐Web架構優化
- 騰訊音樂內容庫資料平臺架構演進實踐架構
- 蘇寧易購CMS架構演進:泰坦平臺的探索與實踐!架構
- 今日頭條架構演進之路——高壓下的架構演進專題架構
- 大型網際網路系統架構演進 BATJ其實無需神化架構BAT
- 各大網際網路公司架構演進之路彙總架構
- Python後端架構演進Python後端架構
- B站直播間基於檢視互動的架構演進架構
- 網易遊戲運維實踐:服務架構及全球通服-AWS峰會演講實錄遊戲運維架構
- 深入解析xLSTM:LSTM架構的演進及PyTorch程式碼實現詳解架構PyTorch
- Serverless 架構落地實踐及案例解析Server架構
- 技術沙龍 | 雲時代下的架構演進—企業雲及雲原生技術落地實踐架構
- 分析視角下銀行業資料平臺架構演進及實現行業架構
- 技術架構演進的思考架構
- Flutter Fish Redux架構演進2.0FlutterRedux架構