青春不老 - B站的微服務(wù)與持續(xù)交付實(shí)踐|IDCF DevOps案例研究

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

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

IDCF指導(dǎo)老師：徐磊、姚冬、王立杰、許舟平

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.2 RPC框架

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

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

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

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

4.3 高性能

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

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

4.4 可用性

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

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

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

• 重試容錯(cuò)：簡(jiǎn)單重試，主備重試，成功率重試，快速失敗。
• 熔斷容錯(cuò)：動(dòng)態(tài)剔除，異常恢復(fù)。

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

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

4.5 一致性

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

• 消息隊(duì)列
• 冪等
• 努力送達(dá)
• 事務(wù)補(bǔ)償

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

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

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

4.7 代碼管理

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

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

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

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

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

5.1 日志平臺(tái)

5.2 監(jiān)控平臺(tái)

5.3 數(shù)據(jù)平臺(tái)

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

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