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

創(chuàng)新互聯(lián)專注于企業(yè)網(wǎng)絡(luò)營銷推廣、網(wǎng)站重做改版、閻良網(wǎng)站定制設(shè)計、自適應品牌網(wǎng)站建設(shè)、H5建站、商城網(wǎng)站制作、集團公司官網(wǎng)建設(shè)、成都外貿(mào)網(wǎng)站建設(shè)、高端網(wǎng)站制作、響應式網(wǎng)頁設(shè)計等建站業(yè)務(wù)，價格優(yōu)惠性價比高，為閻良等各大城市提供網(wǎng)站開發(fā)制作服務(wù)。

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

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

原文首發(fā)于「老廣的印記」

Bilibili簡稱B站，是中國年輕人聚集的文化社區(qū)月活躍用戶量 1.28億人18-35歲用戶占總用戶數(shù)78%(數(shù)據(jù)來源：2019年Q3財報)

一、文化和歷史

B站，被粉絲昵稱為“小破站”，為中國年輕一代高度聚集的文化社區(qū)和視頻平臺，深受年輕用戶的喜愛。經(jīng)過十年多的發(fā)展，圍繞用戶、創(chuàng)作者和內(nèi)容，構(gòu)建了一個源源不斷產(chǎn)生優(yōu)質(zhì)內(nèi)容的生態(tài)系統(tǒng) ，B站已經(jīng)成長為一個涵蓋7000多個興趣圈層的多元文化社區(qū)。
B站原名叫：Mikufans彈幕網(wǎng)。最早的雛形是“初音未來”的粉絲交流社區(qū)。于2010年1月改為提供視頻資源的網(wǎng)站，并正式改名為Bilibili。嗶哩嗶哩的名字來源于《某科學的超電磁炮》，創(chuàng)始人徐逸是這部動漫的狂熱粉絲，女主角御坂美琴用硬幣打出電氣系技能超電磁炮發(fā)出的聲音像Bilibili，徐逸覺得這個名字好聽又好記，所以將Mikufans改名為Bilibili。而御坂美琴發(fā)射電磁炮的硬幣，也成為B站現(xiàn)在的通用貨幣。

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

B站企業(yè)文化關(guān)鍵詞：社區(qū)優(yōu)先，正直誠信，合作共贏，極致執(zhí)行我們可以看到，B站企業(yè)文化關(guān)鍵詞第一位的是社區(qū)優(yōu)先，董事長陳睿曾經(jīng)說過，B站在社區(qū)文化建設(shè)中的兩個初心：

• 為用戶構(gòu)建好的社區(qū)。
• 為創(chuàng)作者搭建施展才華的舞臺。

二、社區(qū)運營生態(tài)

B站2019年的跨年晚會非常成功，收獲了非常多的贊譽，在豆瓣的評分高達9.2，截止二月底累計播放量9075萬次，彈幕總數(shù)294萬，最高在線人數(shù)8000萬，被稱為最懂年輕人的晚會。
B站跨年晚會成功的背后 - “B站對于不同年齡的用戶畫像的深刻理解和把握”。B站的用戶群體大部分是年輕人，可以看這張統(tǒng)計圖，24歲以下的使用人群超過B站用戶的的38%。B站還是中國大的音樂創(chuàng)作平臺之一，中國增長最快的 vlog 社區(qū)，中國大的在線自學平臺等等。這背后大的原因，就在于B站對于不同年齡段用戶的用戶畫像的深刻理解和把握。B站最典型用戶畫像-Z世代。報告顯示，目前，全球Z世代有24億人，占全球人口的32%，而在中國，Z世代的用戶約占20%。針對這樣的一群金主，B站是如何做的呢?形成了以 " 原創(chuàng)內(nèi)容 + 用戶 + 彈幕 " 的交互方式所構(gòu)筑的強粘性社區(qū)生態(tài)環(huán)境， 以及由 “UP 主 - 內(nèi)容 - 社區(qū)用戶”所組成的循環(huán)生態(tài)。這個生態(tài)是一個不斷自增長的閉環(huán)。隨著UP主群體的不斷擴大，社區(qū)內(nèi)容也向多元化發(fā)展，同時又吸引了更多的用戶。B站的這種以內(nèi)容即社交的“打開方式”，正是B站在年輕人中受到歡迎的主要原因。

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

下面我們來介紹B站以用戶價值為導向的需求管理，前面已經(jīng)介紹了B站以用戶價值為核心的企業(yè)文化和運營生態(tài)，如何通過產(chǎn)品研發(fā)和系統(tǒng)實現(xiàn)呢？首先介紹用戶價值為導向的需求管理。
B站的用戶價值以業(yè)務(wù)需求為載體，通過需求分析的篩選，快速地流入到研發(fā)并投產(chǎn)上線，并通過上線后的運營和用戶來持續(xù)優(yōu)化產(chǎn)品，實現(xiàn)整個業(yè)務(wù)價值的閉環(huán)。遵循DevOps的核心思想，持續(xù)快速的迭代反饋，特別是在用戶需求的收集分析管理和用戶反饋上，凸顯出對用戶價值的關(guān)注。接下來我們重點分析。首先是用戶分析，我們看看B站核心用戶畫像。

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

有了清晰的用戶畫像，可以分析出B站的需求主要分為視頻內(nèi)容、用戶體驗、社區(qū)文化和氛圍環(huán)境四類。

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

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

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

對于需求的優(yōu)先級排序，B站有自己管理方法。

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

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

通過以線上與線下相結(jié)合的用戶反饋收集機制，從用戶畫像分析、需求篩選排序到持續(xù)迭代反饋，用戶的價值在DevOps循環(huán)中快速流動持續(xù)交付，B站實現(xiàn)了以用戶價值為導向的需求管理的閉環(huán)。

四、高性能微服務(wù)實踐

一開始B站的技術(shù)以PHP為主，那時的代碼大家喜歡稱之為“KFC全家桶”，一套代碼包含了所有的東西，包括CDN的管理、轉(zhuǎn)碼、多媒體視頻的處理等等，都是通過PHP來完成的，當時就是這樣一套系統(tǒng)支撐著B站的業(yè)務(wù)運行。這么大的一個系統(tǒng)面臨著很多問題：1）代碼維護難度大

• 文檔缺失，上手難度大。
• 理解業(yè)務(wù)邏輯很耗時。

2）基礎(chǔ)架構(gòu)難以擴展

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

3）運維復雜

• 線上配置很復雜，代碼層面沒有設(shè)計路由系統(tǒng)。
• 運維已經(jīng)不堪重負，已經(jīng)禁止添加重寫規(guī)則。

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

4.1 服務(wù)化/微服務(wù)化

1）優(yōu)勢

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

2）挑戰(zhàn)

• 依賴鏈條長，測試常常遇阻，影響測試結(jié)果。
• 各服務(wù)的一致性難以保證。
• 運維成本高，錯誤難定位。
• 基礎(chǔ)設(shè)施，網(wǎng)絡(luò)等要求都比較高。

針對業(yè)務(wù)邏輯進行垂直劃分切割，將一個巨大的服務(wù)體系，按業(yè)務(wù)邏輯切割成單元相對獨立的服務(wù)，如：評論、硬幣、稿件、收藏、feed等，服務(wù)間依賴標準采用RPC調(diào)用。（微服務(wù)架構(gòu)）

4.2 RPC框架

B站一開始是以PHP為主流開發(fā)語言，后來為了快速支撐業(yè)務(wù)的發(fā)展，Node、Java、Python等開發(fā)語言也相繼出現(xiàn)，導致B站的核心技術(shù)棧無法統(tǒng)一，對于微服務(wù)的落地，是兼容所有的語言基于現(xiàn)有架構(gòu)改造，還是選擇統(tǒng)一的技術(shù)棧進行重寫？B站選擇了后者。歸根結(jié)底，重寫后臺工程（主要是賬號相關(guān)的業(yè)務(wù)）是嗶哩嗶哩統(tǒng)一技術(shù)棧的一次嘗試，至于最后為啥選擇了用Go來實現(xiàn)RPC，在2017全球架構(gòu)師峰會上，毛劍解釋很簡單：“主要就是我比較喜歡Go”，看似簡單的一句回答，其實支撐其選擇的原因還在于Go的諸多優(yōu)勢：

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

又或者說，選擇Go非要有個原因么？為什么不能是Go呢？1）B站的RPC框架

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

2）服務(wù)注冊與發(fā)現(xiàn)Discovery

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

3）配置中心

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

4.3 高性能

微服務(wù)化以后，曾經(jīng)的本地調(diào)用變成了遠程調(diào)用，曾經(jīng)的多節(jié)點對等變成了分布式的多節(jié)點，部署越來越復雜，調(diào)用鏈條越來越長，跨機房、跨網(wǎng)絡(luò)、跨機架等都可能造成性能損失。1）鏈路加速（客戶端&服務(wù)端）

• 慢、流量貴（移動端）。
• HTTP DNS & Server List。
• 多CDN加速（規(guī)避風險）。
• 協(xié)議優(yōu)化（壓縮、聚合、根據(jù)網(wǎng)速選擇資源等）。

2）網(wǎng)關(guān)優(yōu)化（go自研，靈活可控）

• 動態(tài)配置
• 協(xié)議裝載
• 業(yè)務(wù)攔截
• 限流保護
• 緩存加速
• 鑒權(quán)
• 反作弊
• 業(yè)務(wù)服務(wù)
• 統(tǒng)計&監(jiān)控

3）優(yōu)化服務(wù)部署架構(gòu)多個組，小集群方式部署，每個組依賴更少的節(jié)點，這樣依賴資源有多套，相互之間也達到了隔離的作用。（一旦某個服務(wù)出現(xiàn)問題，全體受影響）（小集群，多個組，相互隔離，互不影響）

4.4 可用性

1）隔離

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

2）超時

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

3）限流

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

4)容錯

• 重試容錯：簡單重試，主備重試，成功率重試，快速失敗。
• 熔斷容錯：動態(tài)剔除，異?；謴汀?/li>

5）降級

• 調(diào)用鏈路：UI降級，UI異步請求降級，功能降級，讀/寫降級，接入層降級，應用層降級。
• 自動降級：超時降級，統(tǒng)計失敗降級，服務(wù)故障降級，限流降級。
• 手動降級：功能開關(guān)，只讀緩存，寫異步化降級。

每個服務(wù)自身擁有比較健壯的服務(wù)能力，基本每個對外服務(wù)在代碼層都能兼顧到降級、限流、容錯、熔斷、安全、健康檢測。通過鏈路追蹤保證，對錯誤能快速定位和精準定位，降低感知時間和修復時間。6）Playbook 運維操作手冊

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

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

4.5 一致性

1）存儲一致性

• MySQL本地事務(wù)
• 本地事務(wù)+消息隊列
• Binlog

2）服務(wù)一致性

• 消息隊列
• 冪等
• 努力送達
• 事務(wù)補償

4.6 微服務(wù)部署發(fā)布

1）灰度發(fā)布 - 染色

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

RPC meta info & contextserviceA(Red) -> serviceB -> serviceC(Red)2）灰度發(fā)布 - feature flag

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

4.7 代碼管理

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

通過比對分散式管理方式和集中式管理方式，顯而易見，大倉庫的優(yōu)勢在于統(tǒng)一版本依賴、增強協(xié)作、大化復用代碼以及減少版本不一致所引發(fā)的各種線上運營風險。1）大倉庫管理代碼帶來的好處：

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

(引自：Google為什么要把數(shù)十億行代碼放到一個庫中？)
同時，大倉庫所帶來的的挑戰(zhàn)也很明顯，如何保證安全性，如何防止誤操作，如何減少每次checkout代碼的時間和編譯的時間，B站進行了如下的應對。1）目錄級權(quán)限管理2）統(tǒng)一的構(gòu)建系統(tǒng)Bazel

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

3）更高的代碼質(zhì)量要求

• 統(tǒng)一的代碼規(guī)范，便于協(xié)作。
• 單元測試覆蓋率，高質(zhì)量傳承。

4）注重CodeReview，鼓勵溝通

• 保證業(yè)務(wù)邏輯代碼質(zhì)量。
• 信息傳遞，擴充人員備份。
• buildup competence，提升集體戰(zhàn)斗力。
• Ownership機制，責任到人。

五、數(shù)據(jù)運營

數(shù)據(jù)產(chǎn)生價值，該部分內(nèi)容主要介紹B站日志平臺、監(jiān)控平臺和數(shù)據(jù)平臺。

5.1 日志平臺

基于go自研日志平臺Billions，主要由采集、傳輸、切分和檢索四部分構(gòu)成。該系統(tǒng)打破各個業(yè)務(wù)研發(fā)日志壁壘、規(guī)范日志格式、收斂日志接入方式，并統(tǒng)一傳輸、解析和存儲，整個系統(tǒng)高吞吐、低時延、高可用、高可運維性。日志采集agent同時支持服務(wù)鏈路日志采集，隨著微服務(wù)化，一個請求聯(lián)動多個微服務(wù)，當出現(xiàn)問題時，根據(jù)日志里記錄的traceId，可快速檢索出相關(guān)服務(wù)調(diào)用信息、定位故障。

5.2 監(jiān)控平臺

結(jié)束多個監(jiān)控系統(tǒng)并存局面，基于prometheus搭建統(tǒng)一監(jiān)控平臺，覆蓋業(yè)務(wù)層、應用層、中間件、基礎(chǔ)設(shè)施層全面監(jiān)控。開源prometheus存在單點、存儲本地受限、配置維護難三個問題，B站基于聯(lián)邦方式部署prometheus，并將采集到的指標遠端存儲至influxdb中，關(guān)聯(lián)cmdb獲取監(jiān)控對象，界面化配置告警規(guī)則，集中處理告警事件，形成高可用、擴展強、易用監(jiān)控平臺。

5.3 數(shù)據(jù)平臺

讓監(jiān)控、日志數(shù)據(jù)產(chǎn)生更大價值，使用AI技術(shù)對用戶行為日志分析生成用戶畫像，實現(xiàn)精準推薦；根據(jù)流量數(shù)據(jù)實時計算結(jié)果，及時調(diào)整渠道投放以達到最優(yōu)效果等。B站實時數(shù)據(jù)平臺-saber，解決實時計算開發(fā)門檻高、作業(yè)管理難、無統(tǒng)一告警及工程開發(fā)師和算法工程師之間明確分工問題。saber平臺支持BSQL和DAG拖拽式編程，約束輸入源schema，規(guī)范輸出源格式，降低flink開發(fā)門檻；同時解決流式Join、維表Join和實時特征等數(shù)據(jù)處理過程中狀態(tài)、Timer、sql擴展等難點，讓工程無縫對接AI平臺。

六、結(jié)尾

B站十年的風雨路程，是伴隨著這一代人一起見證的。B站這十年，也是同這一代人一起成長的。B站的這些用戶，既是傳播內(nèi)容的目的地，傳播效果的反饋源，更是傳播渠道的探尋者，傳播動力的新引擎。這類人為B站的內(nèi)容生態(tài)，社區(qū)生態(tài)乃至產(chǎn)品生態(tài)提供了源源不斷的動力！
B站堅持的品質(zhì)導向和價值觀優(yōu)先原則為其平臺創(chuàng)造了較高的用戶壁壘，以其對用戶畫像的精準分析，準確把握了用戶的訴求，通過以用戶及商業(yè)價值為導向的需求分析和管理方式，以及日漸完善的監(jiān)控反饋機制，將用戶最關(guān)心，最迫切的需求通過最敏捷的技術(shù)實現(xiàn)呈現(xiàn)在用戶面前，不斷迭代不斷創(chuàng)新。雖然B站目前還未盈利，但他展現(xiàn)出來的良性生態(tài)循環(huán)，未來展現(xiàn)的價值還有更大的想象空間，畢竟：

“一代人終將老去，但總有人正在年輕?！?/blockquote>

本文部分配圖來源于網(wǎng)絡(luò)，內(nèi)容來源于網(wǎng)絡(luò)和B站分享內(nèi)容。

網(wǎng)站名稱：青春不老-B站的微服務(wù)與持續(xù)交付實踐|IDCFDevOps案例研究-創(chuàng)新互聯(lián)
文章鏈接：http://weahome.cn/article/ccdiod.html