713      阿裏雲  技術社區[雲棲]

B站高性能微服務架構

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

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

大家好，我是來自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站發展速度非常快，業務的發展導致團隊也會不停的增長，我們需要考慮各方麵的因素。我們需要有一部分的業務要參與進來，然後梳理出來，再進行一係列架構方麵的重組。

通過整個的服務體係我們可以看到，基本上以命名規則可以看到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。我們的團隊也會做服務巡查。某一個服務如果出現問題都能第一時間來反饋到我們的平台裏。

數據總線中間件

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

數據庫deal

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

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

我們自己魔改了twproxy，這是一個開源的想法。我們自己做了一些二次的開發。因為以前bilitw是單進程，我們這個是一個多進程的魔改負載均衡的組件。

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

B站發展到現在，微服務還隻是一個剛起步的階段，我們也在微服務這條路上慢慢探索適合我們的一個微服務架構。我認為適合企業本身的微服務就是最好的。

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

原文地址：https://www.itdks.com/dakashuo/detail/1179

最後更新：2017-07-03 16:32:05

  上一篇：  從摩拜單車的雲技術看物聯網與雲計算的關係

  下一篇：  揭開神經網絡加速器的神秘麵紗之DianNao