B站高性能微服務架構
本文內容來源於任偉在【滬江技術沙龍】-漫談微服務架構實踐上的主題演講，IT大咖說為滬江技術沙龍獨家視頻知識分享平台。
內容摘要
Bilibili作為一個大型彈幕視頻網站，在競爭日益激烈的互聯網行業中，開始重視技術生態的演進，探索尋求適合企業本身的一個微服務架構。本次分享主要講述了B站高性能微服務架構的演進。
嘉賓演講視頻
https://t.cn/RSHqFlg
大家好，我是來自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站發展到現在，微服務還只是一個剛起步的階段，我們也在微服務這條路上慢慢探索適合我們的一個微服務架構。我認為適合企業本身的微服務就是最好的。
我今天要分享的就這麼多，謝謝！
點擊展開全文
TAG:田間小錫 |