青春不老 - 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站分享內容。