B站高性能微服務架構

本文內容來源於 任偉 在 【滬江技術沙龍】-漫談微服務架構實踐 上的主題演講，IT大咖說爲滬江技術沙龍獨家視頻知識分享平臺。

內容摘要

Bilibili做爲一個大型彈幕視頻網站，在競爭日益激烈的互聯網行業中，開始重視技術生態的演進，探索尋求適合企業自己的一個微服務架構。本次分享主要講述了B站高性能微服務架構的演進。

嘉賓分享視頻地址： t.cn/RX8fFAn

你們好，我是來自bilibili的任偉。今天的分享分爲三個部份內容：

• 曾經的價格體系。

• 面臨的一些痛點問題。

• 高性能微服務架構在B站的落地。

曾經的價格體系

B站從成立至今已經有將近八年的時間了，可是從前兩年咱們纔開始重視整個的技術生態的演進。在整個B站的代碼體系裏面，咱們曾經也把B站的老代碼稱之爲全家桶。由於它是一套代碼，涵蓋了幾乎全部bilibili裏面的業務體系。咱們如今的引進方向以科研爲主，整個B站光是網站這一塊，就有不少的分支，而整個的分支對應的域名也不少。

B站之前代碼的體系從安全體系上來說，咱們進行了一系列的拆分。整個的代碼倉庫主要分爲三個部分，一是主站的業務邏輯，還有一個是分發管理的邏輯，以及配置文件。配置文件總體的發佈是一套很是繁雜的流程，它用腳本的方式把整個配置文件慢慢的生成，而這些跟自己主張的代碼邏輯是隔離開來的。

我是一個工做不少年的PHP研發。在接觸B站以前，我一直認爲PHP的業務結構開發速度會很是快。可是瞭解了B站的代碼就會發現，其實用PHP語言體系來作的事情很是多。就目前而言，整個B站的運維體系的工具都是由PHP來完成的。由於咱們是一個視頻類的網站，最重要的就是視頻資源的管理，而這個調度其實一開始也是由PHP來完成的。

下面圖片是一個咱們的業務集羣，主要分三大塊，一塊是面向移動端的服務集羣，一個是面向PC端的服務集羣，還有一個就是面向彈幕的。

面臨的一些痛點問題

整個B站曾經的體系是很是龐雜的，這麼大的一個系統面臨着不少問題。

代碼和文檔問題

就代碼來講，維護的難度很是大。對於研發而言，若是咱們只是關注某一塊的業務邏輯，就好像管中窺豹。並且最重要的是它文檔缺失。雖然說一個好的編碼習慣就是一個好的文檔，但在業務量或整個體系比較龐大的狀況下，文檔和代碼仍是有本質區別的。

B站是基於各類網站慢慢成長起來的一個企業，因此當時在作這塊的時候沒有特別重視，文檔一直有比較大的缺失，致使代碼維護很是麻煩。

基礎架構

整個的基礎架構是基於織夢CMS，是一個比較流行的開源的內容管理系統。絕大多數業務邏輯咱們作了一些深度的定製，致使通常研發很難搞定前面底層裏的一些邏輯。

業務機會聚合在一塊兒，不易被擴展和拆分。B站在發展到前兩年的時候，讓運維獨立去搭一套整個B站的擴展體系並非那麼容易，B站的運行環境基本上只能經過創始人來擴展咱們的負載。

運維複雜

運維複雜，由於配置也是至關複雜。後來已經不容許在運維再增長業務上的一些重寫邏輯，只有讓代碼這邊本身去處理。因此重構優化，咱們已經提上了日程。

咱們公司成立的基礎是一個天才型選手，之前在那套系統加入了一些黑科技的東西，但同時就限制了公司團隊的發展。

基於這樣的一些重點問題，咱們在去年開始思考怎麼來解決B站目前面臨的這些問題。由於B站發展速度很是快，業務的發展致使團隊也會不停的增加，咱們須要考慮各方面的因素。咱們須要有一部分的業務要參與進來，而後梳理出來，再進行一系列架構方面的重組。

高性能微服務如何在B站落地

經過整個的服務體系咱們能夠看到，基本上以命名規則能夠看到service裏面的一些內部服務。對於終端和PC端，咱們都是以show和interface做爲做爲項目向外透露接口，他們的區別就在於show是一個單純的業務，它有緊急預案和service。可是interface會作一些數據的聚合。服務間的依賴標準主要是RPC。

介紹完大致框架以後，咱們先看一下爲何當時B站會選擇go語言做爲技術站。咱們選擇go主要是由於它的執行和開發效率很是的高效。相比其餘語言，優點仍是挺明顯的。好比咱們主站的首頁的動態圖，每五秒鐘須要獲取各個分區裏面的最新稿件，訂單訪問量是很是大的。利用go服務能夠明顯地感受到移動端的訪問量佔整個B站的訪問量已經達到了60%以上，可是他那邊基本上全部的服務接口都不走CDN，直接打到元，他們那邊量也是很是大，可是也沒有出過什麼錯。

B站go語言成長很是迅速，由於它的背景是google，生態也比較豐富，支持kafka、canel、hbase這些比較流行的風格式管理框架。鑑於此，咱們就選擇了go語言做爲咱們整個公司的在技術上的統一。並且相對而言，它的調用效率要比http比較高，就是咱們不走apI接口接收內部的RPC。

爲何說B站微服務在整個經營效率上會這麼高呢，除了它自己語言體系上沒有其餘語言那麼臃腫以外，咱們還作了一些努力。好比在整個的對外服務的這一層上，基本上沒有任何的請求能夠直接打到DB，所有是緩存。咱們都是經過多層緩存機制來保障的。

我以爲微服務最重要的一點就是服務隔離。在實際項目中咱們也遇到不少問題。由於公共資源，致使某一個服務和資源掛鉤，會拖垮相應的服務，因此說服務隔離很是重要。

選擇go的另一個重要緣由就是它自己跟docker的結合有自然的優點。由於go語言的運行環境很是的精良，它不須要依賴於任何的其餘的環境。因此咱們動態的管理相對於其餘項目來說的，是整個公司裏面最乾淨的docker。咱們的團隊也會作服務巡查。某一個服務若是出現問題都能第一時間來反饋到咱們的平臺裏。

go語言的幾個基礎

數據總線中間件

數據總線中間件，叫Databus。它是一個面向redis協議背靠kafka的消息中間件，它是基於內地市場放上的行爲，主要目的就是用來deal。

數據庫deal

咱們主張直接更新緩存，並把消息推送到數據總線，而後由數據總線來更新數據庫。

咱們這邊自己也有一些稿件的時候，好比說用戶提交的一些視頻，在咱們這邊的話會有一個基於canal的go服務，這個服務的主要做用就是在於監聽數據庫日誌，來解析出數據庫裏面的更新和參數方程，來更新緩存。

咱們本身魔改了twproxy，這是一個開源的想法。咱們本身作了一些二次的開發。由於之前bilitw是單進程，咱們這個是一個多進程的魔改負載均衡的組件。

配置中心disconf也是咱們本身研發。基本上咱們以本身造文字爲主了。也作了一套本身的小文件存儲系統BFS。這套系統跟當前比較流行的一些雲存儲仍是很像的，它的吞吐量足夠大，擴展性也足夠好。

B站發展到如今，微服務還只是一個剛起步的階段，咱們也在微服務這條路上慢慢探索適合咱們的一個微服務架構。我認爲適合企業自己的微服務就是最好的。

我今天要分享的就這麼多，謝謝！

推薦文章

• 滬江技術經理黃凱：滬江任務調度系統微服務化介紹

原文地址：t.cn/RSHqFlg