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

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

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

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

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

Bilibili簡稱B站，是中國年輕人聚集的文化社群

月活躍使用者量 1.28億人

18-35歲使用者佔總使用者數78%

(資料來源：2019年Q3財報)

一、文化和歷史

B站，被粉絲暱稱為“小破站”，為中國年輕一代高度聚集的文化社群和影片平臺，深受年輕使用者的喜愛。經過十年多的發展，圍繞使用者、創作者和內容，構建了一個源源不斷產生優質內容的生態系統 ，B站已經成長為一個涵蓋7000多個興趣圈層的多元文化社群。

B站原名叫：Mikufans彈幕網。最早的雛形是“初音未來”的粉絲交流社群。於2010年1月改為提供影片資源的網站，並正式改名為Bilibili。

嗶哩嗶哩的名字來源於《某科學的超電磁炮》，創始人徐逸是這部動漫的狂熱粉絲，女主角御坂美琴用硬幣打出電氣系技能超電磁炮發出的聲音像Bilibili，徐逸覺得這個名字好聽又好記，所以將Mikufans改名為Bilibili。而御坂美琴發射電磁炮的硬幣，也成為B站現在的通用貨幣。

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

B站企業文化關鍵詞：社群優先，正直誠信，合作共贏，極致執行

我們可以看到，B站企業文化關鍵詞第一位的是社群優先，董事長陳睿曾經說過，B站在社群文化建設中的兩個初心：

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

二、社群運營生態

B站2019年的跨年晚會非常成功，收穫了非常多的讚譽，在豆瓣的評分高達9.2，截止二月底累計播放量9075萬次，彈幕總數294萬，最高線上人數8000萬，被稱為最懂年輕人的晚會。

B站跨年晚會成功的背後 - “B站對於不同年齡的使用者畫像的深刻理解和把握”。

B站的使用者群體大部分是年輕人，可以看這張統計圖，24歲以下的使用人群超過B站使用者的的38%。

B站還是中國最大的音樂創作平臺之一，中國增長最快的 vlog 社群，中國最大的線上自學平臺等等。

這背後最大的原因，就在於B站對於不同年齡段使用者的使用者畫像的深刻理解和把握。

B站最典型使用者畫像-Z世代。

報告顯示，目前，全球Z世代有24億人，佔全球人口的32%，而在中國，Z世代的使用者約佔20%。

針對這樣的一群金主，B站是如何做的呢?

形成了以 " 原創內容 + 使用者 + 彈幕 " 的互動方式所構築的強粘性社群生態環境， 以及由 “UP 主 - 內容 - 社群使用者”所組成的迴圈生態。

這個生態是一個不斷自增長的閉環。隨著UP主群體的不斷擴大，社群內容也向多元化發展，同時又吸引了更多的使用者。

B站的這種以內容即社交的“開啟方式”，正是B站在年輕人中受到歡迎的主要原因。

三、使用者價值為導向的需求管理

下面我們來介紹B站以使用者價值為導向的需求管理，前面已經介紹了B站以使用者價值為核心的企業文化和運營生態，如何透過產品研發和系統實現呢？首先介紹使用者價值為導向的需求管理。

B站的使用者價值以業務需求為載體，透過需求分析的篩選，快速地流入到研發並投產上線，並透過上線後的運營和使用者來持續最佳化產品，實現整個業務價值的閉環。遵循DevOps的核心思想，持續快速的迭代反饋，特別是在使用者需求的收集分析管理和使用者反饋上，凸顯出對使用者價值的關注。接下來我們重點分析。

首先是使用者分析，我們看看B站核心使用者畫像。

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

有了清晰的使用者畫像，可以分析出B站的需求主要分為影片內容、使用者體驗、社群文化和氛圍環境四類。

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

需求的收集主要從兩個方面：

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

對於需求的優先順序排序，B站有自己管理方法。

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

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

透過以線上與線下相結合的使用者反饋收集機制，從使用者畫像分析、需求篩選排序到持續迭代反饋，使用者的價值在DevOps迴圈中快速流動持續交付，B站實現了以使用者價值為導向的需求管理的閉環。

四、高效能微服務實踐

一開始B站的技術以PHP為主，那時的程式碼大家喜歡稱之為“KFC全家桶”，一套程式碼包含了所有的東西，包括CDN的管理、轉碼、多媒體影片的處理等等，都是透過PHP來完成的，當時就是這樣一套系統支撐著B站的業務執行。

這麼大的一個系統面臨著很多問題：

1）程式碼維護難度大

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

2）基礎架構難以擴充套件

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

3）運維複雜

• 線上配置很複雜，程式碼層面沒有設計路由系統。
• 運維已經不堪重負，已經禁止新增重寫規則。

B站成立的基礎是一個天才型選手，以前在那套系統加入了一些黑科技的東西，但同時也就限制了公司團隊的發展，基於這樣的一些重點問題，隨著業務的發展和團隊的不停增長，解決B站目前面臨的這些問題勢在必行。

4.1 服務化/微服務化

1）優勢

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

2）挑戰

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

針對業務邏輯進行垂直劃分切割，將一個巨大的服務體系，按業務邏輯切割成單元相對獨立的服務，如：評論、硬幣、稿件、收藏、feed等，服務間依賴標準採用RPC呼叫。

（微服務架構）

4.2 RPC框架

B站一開始是以PHP為主流開發語言，後來為了快速支撐業務的發展，Node、Java、Python等開發語言也相繼出現，導致B站的核心技術棧無法統一，對於微服務的落地，是相容所有的語言基於現有架構改造，還是選擇統一的技術棧進行重寫？B站選擇了後者。

歸根結底，重寫後臺工程（主要是賬號相關的業務）是嗶哩嗶哩統一技術棧的一次嘗試，至於最後為啥選擇了用Go來實現RPC，在2017全球架構師峰會上，毛劍解釋很簡單：“主要就是我比較喜歡Go”，看似簡單的一句回答，其實支撐其選擇的原因還在於Go的諸多優勢：

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

又或者說，選擇Go非要有個原因麼？為什麼不能是Go呢？

1）B站的RPC框架

• 基於Go原生的網路庫“net/rpc”。
• Gob進行struct的序列化，不需要複製額外的程式碼，使用較為方便。
• 方法級的超時控制。
• 上下文context的支援。

2）服務註冊與發現Discovery

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

3）配置中心

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

4.3 高效能

微服務化以後，曾經的本地呼叫變成了遠端呼叫，曾經的多節點對等變成了分散式的多節點，部署越來越複雜，呼叫鏈條越來越長，跨機房、跨網路、跨機架等都可能造成效能損失。

1）鏈路加速（客戶端&服務端）

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

2）閘道器最佳化（go自研，靈活可控）

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

3）最佳化服務部署架構

多個組，小叢集方式部署，每個組依賴更少的節點，這樣依賴資源有多套，相互之間也達到了隔離的作用。

（一旦某個服務出現問題，全體受影響）

（小叢集，多個組，相互隔離，互不影響）

4.4 可用性

1）隔離

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

2）超時

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

3）限流

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

4)容錯

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

5）降級

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

每個服務自身擁有比較健壯的服務能力，基本每個對外服務在程式碼層都能兼顧到降級、限流、容錯、熔斷、安全、健康檢測。

透過鏈路追蹤保證，對錯誤能快速定位和精準定位，降低感知時間和修復時間。

6）Playbook 運維操作手冊

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

7）運維層面，定期故障演練，確保流程可被正確可靠執行。

4.5 一致性

1）儲存一致性

• MySQL本地事務
• 本地事務+訊息佇列
• Binlog

2）服務一致性

• 訊息佇列
• 冪等
• 努力送達
• 事務補償

4.6 微服務部署釋出

1）灰度釋出 - 染色

• 在PaaS平臺上選擇灰度釋出-染色，定義染色標籤。
• 在IaaS平臺上開啟“環境代理”虛擬機器。
• 映象選擇環境代理hasson-base最小配置即可。
• 在hasson的虛擬機器錄入染色標籤，按需配置測試介面。
• DNS指向hasson IP，即可開始測試。

RPC meta info & context

serviceA(Red) -> serviceB -> serviceC(Red)

2）灰度釋出 - feature flag

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

4.7 程式碼管理

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

透過比對分散式管理方式和集中式管理方式，顯而易見，大倉庫的優勢在於統一版本依賴、增強協作、最大化複用程式碼以及減少版本不一致所引發的各種線上運營風險。

1）大倉庫管理程式碼帶來的好處：

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

(引自：Google為什麼要把數十億行程式碼放到一個庫中？)

同時，大倉庫所帶來的的挑戰也很明顯，如何保證安全性，如何防止誤操作，如何減少每次checkout程式碼的時間和編譯的時間，B站進行了如下的應對。

1）目錄級許可權管理

2）統一的構建系統Bazel

• 支援多種開發語言。
• 依賴分析增量編譯。
• 可按需進行擴充套件。

3）更高的程式碼質量要求

• 統一的程式碼規範，便於協作。
• 單元測試覆蓋率，高質量傳承。

4）注重CodeReview，鼓勵溝通

• 保證業務邏輯程式碼質量。
• 資訊傳遞，擴充人員備份。
• buildup competence，提升集體戰鬥力。
• Ownership機制，責任到人。

五、資料運營

資料產生價值，該部分內容主要介紹B站日誌平臺、監控平臺和資料平臺。

5.1 日誌平臺

基於go自研日誌平臺Billions，主要由採集、傳輸、切分和檢索四部分構成。該系統打破各個業務研發日誌壁壘、規範日誌格式、收斂日誌接入方式，並統一傳輸、解析和儲存，整個系統高吞吐、低時延、高可用、高可運維性。

日誌採集agent同時支援服務鏈路日誌採集，隨著微服務化，一個請求聯動多個微服務，當出現問題時，根據日誌裡記錄的traceId，可快速檢索出相關服務呼叫資訊、定位故障。

5.2 監控平臺

結束多個監控系統並存局面，基於prometheus搭建統一監控平臺，覆蓋業務層、應用層、中介軟體、基礎設施層全面監控。開源prometheus存在單點、儲存本地受限、配置維護難三個問題，B站基於聯邦方式部署prometheus，並將採集到的指標遠端儲存至influxdb中，關聯cmdb獲取監控物件，介面化配置告警規則，集中處理告警事件，形成高可用、擴充套件強、易用監控平臺。

5.3 資料平臺

讓監控、日誌資料產生更大價值，使用AI技術對使用者行為日誌分析生成使用者畫像，實現精準推薦；根據流量資料實時計算結果，及時調整渠道投放以達到最優效果等。

B站實時資料平臺-saber，解決實時計算開發門檻高、作業管理難、無統一告警及工程開發師和演算法工程師之間明確分工問題。saber平臺支援BSQL和DAG拖拽式程式設計，約束輸入源schema，規範輸出源格式，降低flink開發門檻；同時解決流式Join、維表Join和實時特徵等資料處理過程中狀態、Timer、sql擴充套件等難點，讓工程無縫對接AI平臺。

六、結尾

B站十年的風雨路程，是伴隨著這一代人一起見證的。B站這十年，也是同這一代人一起成長的。B站的這些使用者，既是傳播內容的目的地，傳播效果的反饋源，更是傳播渠道的探尋者，傳播動力的新引擎。這類人為B站的內容生態，社群生態乃至產品生態提供了源源不斷的動力！

B站堅持的品質導向和價值觀優先原則為其平臺創造了較高的使用者壁壘，以其對使用者畫像的精準分析，準確把握了使用者的訴求，透過以使用者及商業價值為導向的需求分析和管理方式，以及日漸完善的監控反饋機制，將使用者最關心，最迫切的需求透過最敏捷的技術實現呈現在使用者面前，不斷迭代不斷創新。

雖然B站目前還未盈利，但他展現出來的良性生態迴圈，未來展現的價值還有更大的想象空間，畢竟：

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

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