青春不老 - B站的微服務與持續交付實踐|IDCF DevOps案例研究

內容來源：DevOps案例深度研究第4期 – B站 DevOps實踐研究戰隊（本文只展示部分PPT及研究成果，全程視頻請移步文末）轉載請注明出處。

本案例內容貢獻者：曹坤良，董沙莎，過佳昱，廖定，李晶晶，李思源，歐美玲，任廣印，Ruth，姚丹，張楠

IDCF指導老師：徐磊、姚冬、王立杰、許舟平

原文首發于「老廣的印記」

• 徐逸：創始人，意見領袖，重度動漫迷。曾任執行董事。2019年卸任法人代表和執行董事，目前負責社區運營。
• 陳睿：董事長兼CEO。曾任中國最早的互聯網軟件企業之一金山軟件聯合創始人。2011年，陳睿以天使投資人的身份加入B站；2014年，正式加入B站擔任董事長。
• 李旎：首席運營官。

• 為用戶構建好的社區。
• 為創作者搭建施展才華的舞臺。

• 二次元用戶（核心目標用戶）：可以追番劇，了解二次元文化，希望能認識更多同好。
• UGC創作者（核心目標用戶）：希望有一個大平臺可以讓自己作品被看到，收到大家認同。
• 直播愛好者：希望有平臺能展示自己的才能。
• 非二次元用戶：只是單純地希望能找到有序的視頻，或跟隨喜歡的UP主或主播而來。

• 視頻內容主要包括番劇、原創視頻及UP主自制類視頻功能，加上以用戶為中心的頁面布局、交互等用戶體驗設計，這兩類需求針對核心用戶占比會比較大，也呼應了前面的注重核心用戶價值和體驗。
• 社區文化類主要包括會員管理及支撐圈層的需求；氛圍環境類包括彈幕和交流環境以及相關審核的需求，這兩塊為共同愛好者持續的交流分享營造一個良好的氛圍，為核心功能提供支撐，這是B站重點響應的部分。

• 一方面通過全面分析商業價值、用戶價值、分解轉換為具體實現的需求；
• 另一方面在快速響應需求上線以后，收集用戶反饋來持續完善產品的需求。

• 首先它是基于用戶及商業價值的分析，基于核心用戶的訴求和用戶畫像，優先考慮需求的迫切程度，通過良好的用戶體驗既維持老用戶的粘度。對于系統運行穩定的一些非功能性的需求，也作為重點的排序考慮。
• 另外基于商業價值考量，針對付費用戶，用付費情況來衡量需求價值，更量化且與商業接軌。
• 考慮用戶與商業價值分析的同時，B站也會使用四象限法來進行需求的篩選和排序，通過需求的用戶范圍、發生頻率和成本、效益，進行綜合分析排序，確保用戶價值價值較高的需求能夠優先、快速地進入迭代循環，快速地上線并得到用戶的反饋。

B站采用多種方式來收集用戶的反饋，不僅包括了線下渠道的主動收集，而且還通過日志采集、設置埋點等多種手段，線上自動采集運營數據。對于線上的采集，采取了收集用戶行為和用戶數據的方式，首先與業務方一起繪制需采集業務場景涉及的系統鏈路，然后系統分布分別在客戶端和服務端設置埋點，采集用戶行為數據，記錄日志。通過新功能灰度上線后目標用戶數據采集和分析，形成對需求的快速反饋，持續打磨完善產品。

• 文檔缺失，上手難度大。
• 理解業務邏輯很耗時。

• 基于織夢CMS，一個開源的內容管理系統。
• 系統做了深度定制，底層邏輯沒幾個人能搞定。
• 業務聚合在一起，不易被擴展和拆分。
• 運行環境基本上只能通過創始人來擴展。

• 線上配置很復雜，代碼層面沒有設計路由系統。
• 運維已經不堪重負，已經禁止添加重寫規則。

4.1 服務化/微服務化

• 各個服務獨立開發。
• 分工明確，各自迭代。
• 單獨模塊獨立部署。
• 可獨立進行測試。

• 依賴鏈條長，測試常常遇阻，影響測試結果。
• 各服務的一致性難以保證。
• 運維成本高，錯誤難定位。
• 基礎設施，網絡等要求都比較高。

4.2 RPC框架

• 強大的標準庫，解決了B站在視頻方面的問題。
• 和Docker容器化良好的支持。
• 二進制發布，優秀的執行效率和開發效率。
• 易學易用上手快。
• 背靠Google大廠，豐富的開發者生態。
• 支持幾乎所有主流的框架。

• 基于Go原生的網絡庫“net/rpc”。
• Gob進行struct的序列化，不需要拷貝額外的代碼，使用較為方便。
• 方法級的超時控制。
• 上下文context的支持。

• 及時同步服務上下線事件。
• 服務發現節點自我發現。
• CP模式：依賴ZK的心跳進行廣播（ZK心跳遇到抖動時候，容易出現全服務下線 ，所以B站會根據服務節點變化數進行判斷是否放棄本次變更，進行容錯）。
• AP模式：polling + ping（優先保證高可用，犧牲部分一致性，但最終達到一致）。

• 利用mysql做存儲管理相關配置信息。
• 通過http long polling來檢查配置變更確保及時生效。
• 獲取服務ip和版本，記錄meta信息，實現服務發現的功能。

4.3 高性能

• 慢、流量貴（移動端）。
• HTTP DNS & Server List。
• 多CDN加速（規避風險）。
• 協議優化（壓縮、聚合、根據網速選擇資源等）。

• 動態配置
• 協議裝載
• 業務攔截
• 限流保護
• 緩存加速
• 鑒權
• 反作弊
• 業務服務
• 統計&監控

4.4 可用性

• 服務隔離：壓力分流，穩定性高，物理隔離。
• 輕重隔離：核心穩定，快慢分離，流量遷移。
• 物理隔離：進程隔離，集群隔離，機房隔離。e.g. 機器隔離，容器隔離

• 設置超時：連接超時，讀取超時，寫入超時。e.g. 避免擠壓，防止雪崩
• 合理超時：避免過短，避免過長，動態設置。

• 流量限流：accept，connection，thread。
• 資源限流：連接池，線程池。
• 請求限流：總數，時間窗口，平滑限流。
• 分布式限流：redis + lua，nginx + lua。
• 接入層限流：nginx limit_req，nginx limit_conn

• 重試容錯：簡單重試，主備重試，成功率重試，快速失敗。
• 熔斷容錯：動態剔除，異常恢復。

• 調用鏈路：UI降級，UI異步請求降級，功能降級，讀/寫降級，接入層降級，應用層降級。
• 自動降級：超時降級，統計失敗降級，服務故障降級，限流降級。
• 手動降級：功能開關，只讀緩存，寫異步化降級。

• 依賴的接口，必須加上熔斷。
• 當接口出現故障，自動熔斷，普羅米修斯出熔斷數據曲線圖，并且報警。
• 當超過N分鐘，服務仍然不恢復，可以使用配置中心的推送功能，打開強制熔斷，不再依賴接口。
• 當依賴方告知服務恢復，重新關閉熔斷開關，變成自動熔斷狀態。

4.5 一致性

• MySQL本地事務
• 本地事務+消息隊列
• Binlog

• 消息隊列
• 冪等
• 努力送達
• 事務補償

4.6 微服務部署發布

• 在PaaS平臺上選擇灰度發布-染色，定義染色標簽。
• 在IaaS平臺上開啟“環境代理”虛擬機。
• 鏡像選擇環境代理hasson-base最小配置即可。
• 在hasson的虛擬機錄入染色標簽，按需配置測試接口。
• DNS指向hasson IP，即可開始測試。

• 盡早的進入主干，可以跟灰度發布結合使用（金絲雀發布），需要使用統一的flag機制。
• 需要清理不再需要的flags，需要開發者養成良好習慣，正確使用flags，否則容易顯得很亂。

4.7 代碼管理

• 隨著業務發展，基礎庫變更頻繁，推進困難。
• 雖然重視代碼質量，但流程不夠自動化，完全靠自覺。
• 測試都積壓在發版前，質量難保證，發版風險大。
• 版本管理非常復雜，代碼復用率低下，維護成本高。

• 統一版本控制
• 廣泛的代碼共享和重用
• 簡化依賴管理，避免菱形依賴
• 原子修改
• 大規模重構
• 跨團隊協作
• 靈活的團隊邊界和代碼所有權
• 代碼可見性以及清晰的樹形結構提供了隱含的團隊命名空間

• 支持多種開發語言。
• 依賴分析增量編譯。
• 可按需進行擴展。

• 統一的代碼規范，便于協作。
• 單元測試覆蓋率，高質量傳承。

• 保證業務邏輯代碼質量。
• 信息傳遞，擴充人員備份。
• buildup competence，提升集體戰斗力。
• Ownership機制，責任到人。

5.1 日志平臺

5.2 監控平臺

5.3 數據平臺

“一代人終將老去，但總有人正在年輕。”

本文部分配圖來源于網絡，內容來源于網絡和B站分享內容。