嗶哩嗶哩（B站）的前端之路

嗶哩嗶哩（B站）的前端之路

2017年即將過去了，總結一下B站的前端進階之路

過去的開發模式中，我們採用了以後端為主的 MVC 架構方式。具體來說，每次項目評審後，前後端會先一起約定好介面，之後分別進行開發，開發完，前端需要把頁面提供給後端，後端配置上數據，然後返回出來。正式基於這樣的開發模式，導致了總工作量的增加，同時溝通和聯調成本的消耗也十分顯著。

前後端分離

為了擺脫這種前後端過分依賴的情況，（其實前端也不想每次修改或者發布都要後端這邊發布，後端也不想每次前端只改個標題，都要發布一下,影響服務的穩定性），那麼先從前後端分離開始吧~

前後端分離，最基本的兩種模式，有中間層和沒有中間層。

第一種，沒有web中間層就很簡單，提供一個html模板放到靜態資源機上面，html模板裡面引用了所需的js和css

,訪問頁面的時候 把這個靜態模板返回給用戶，然後執行js 在瀏覽器端通過ajax請求api拿到數據，渲染頁面。

（前後端分離）

第二種，有node中間層，隨著2009年，Node的橫空出世，把前端慢慢的推向了後端，有了node之後，JavaScript可以做更多的事情。

B站，一開始做前後端分離的時候，也確實按照第一種方式去做的,現在還有一些頁面仍然是這種模式,例如:https://www.bilibili.com/account/history (可查看網頁源代碼)。對於不需要seo的頁面來說，是一個不錯的方式。前端開發完成之後，通過webpack打包出對應的js和css 上傳到cdn上面，然後將webpack打包出來的 引用了對應的資源的html文件 上傳到一台專門的靜態機上面，然後運維配置路由 將頁面流量導過去就好了。後端的同學只需要提供對應的api介面就可以。前後端分開維護，自己按照自己的節奏走，降低了頁面與服務的耦合度

這種方式確實是一種很快能夠進行前後端分離的方法。我們花了一段時間，在pc端使用vue 進行重構，移動端H5端 用react

進行了重構。 進度很快，但是也慢慢展現出了弊端。

首屏的時候，因為他要等待資源載入完成，然後再進行渲染，會導致了首屏有白屏，如果是單頁面還好，如果是spa應用 那麼 他的載入時間就會變得很長，白屏時間會很影響用戶體驗，再有就是由於國內的搜索公司 對於spa 應用沒有很好的兼容，導致了客戶端渲染會對seo非常的不友好，有seo 需求的頁面就很迫切的需要服務端渲染。

（B站的首頁，右邊模塊做了服務端渲染，左邊模塊沒有做服務端渲染）

那麼，依賴node 進行服務端渲染就被提上了日程。

選型

首先進行node 框架的選型，市面上主流框架有三種，hapi express koa ,還有一些是經過一些封裝和定製的框架，例如 eggjs等

一開始我就把eggjs 排除在外了，第一

因為eggjs,的功能很強大，有很多功能，多到有些根本用不著，從而導致了他會重 不輕量級，第二，eggjs對於我來說是個黑盒，如果有什麼問題，我解決起來將會花費很長的時間。（但是有很多地方 我還是借鑒了eggjs的，畢竟 很強大）

然後剩下的三種框架，express的使用相對簡單，文檔也比較多

比較全面，所以我就選擇了express(後來還是重構掉了 = =!)

然後是前端框架的選型 因為前端框架主流的有很多，ng r v 等等，我站在用的是react和vue, 他們有個優勢就是可以進行前後端同構，一樣的邏輯不用寫兩份，很棒

（同構邏輯大概如此吧）

由於之前前後端分離的時候，pc

上面已經再用vue 進行了重構，所以自然，這次服務端渲染也建立在vue上面 用的是vue ssr (這也為我後面的一個想法埋下了伏筆)

首先 我們選擇一個簡單的頁面來做打樣，就用tag頁吧（被神選中的孩子：https://www.bilibili.com/tag/3503159 ）

開發

目錄結構

- client 【客戶端代碼 同構代碼】

- build 【構建相關】

- PC 【pc 端 vue項目】

- package.json

- config

- config.local.js 【本地開發配置】

- dist 【構建目錄 掛載資源目錄】

- server 【服務端代碼】

- controller 【控制器】

- PC

- route.js

- core [核心代碼庫]

- service [方法庫]

- view [視圖]

- PC [vue 構建後文件]

- tag.html [構建後的模板]

- tag.json [構建後的bundle]

- manifest.json

- apps.js [啟動項]

在一開始設計的時候，客戶端代碼和服務端代碼放在同一個git庫裡面，client裡面是vue的代碼和webpack的打包邏輯。Server里是服務端的代碼，用的是類mvc結構。

Client裡面的vue的開發代碼，參照的就是vue ssr 官方給的例子來做的，用的是 createBundleRender方法

const { createBundleRenderer } = require("vue-server-renderer")const renderer = createBundleRenderer(serverBundle, {... })

構建配置也是用的推薦的配置（參考：https://ssr.vuejs.org/zh/build-config.html ）

簡單來說，就是提供兩個入口，一個entry-client.js,主要是客戶端的執行入口， 打包出來的是客戶端的引用代碼集合（manifest），另外一個是entry-server.js 打包出來的是服務端運行的邏輯,整合到了bundle.json裡面。然後傳給上面的createBundleRender方法就可以了

對於server文件夾裡面的邏輯就非常簡單了，core裡面是啟動項目的一些express的核心代碼 路由註冊什麼的邏輯，值得一說的是，這邊的路由，借鑒了eggjs的路由註冊方式，稍微做了一點修改，用的是配置化的方式

配置優於代碼，將訪問地址和對應的controller 做了關聯

這邊還有一個filter 其實就是在執行controller之前 註冊進一個middlewares 優先執行（其實這邊有點局限性，後處理沒法做）

這邊我忽略了壓力測試，壓力測試我後面再說把

上線部署

上線部署用的是docker

來部署的，配置是1C 4G的配置，用了兩個實例來運行，（之前的構建鏡像邏輯什麼的 就不具體介紹了）

上線之後 每天的訪問量大概在100W左右，服務表現挺穩定，期間出現了一個bug,就是 這邊有一個狀態與用戶的登陸狀態有關，所以在服務端請求介面的時候，需要帶上cookie去請求，當時忘記加了 後來加上，發現這個有點弊端 比較麻煩

需要在調用vuesssr的時候帶在context 裡面，然後asyncData方法裡面都要一層一層的傳遞，最後在action 裡面拿到，帶給api

這時候 我們再來看下tag

頁

(不錯 把數據都帶上了)

重構

其實也沒過多久，大概三個月吧，node的版本漲的很快，在7.6版本之後，node 就支持了async/await

語法糖，不需要再用yield 和*函數了，那麼 無疑 koa 是對於await/async 支持最好的，我們果斷放棄了express,選擇了koa2 進行重構

其實不單單是koa2對於async的支持，另外一個原因在於，我們koa 是洋蔥式的執行方式，這樣就解決了上面我說的，只有controller的前處理，沒有後處理，這樣子我就可以很方便的去執行前後處理。Koa的執行效率也要好於express.

上面我說過，選擇vue 對後面重構埋下了一個伏筆就在這裡

首先，我給項目接入了配置中心，配置中心是幹嘛用的呢？ 用來記錄腳本的版本號，這樣子我就可以很輕鬆的通過配置中心來控制前端頁面使用什麼版本的腳本。而不用因為改了個腳本的版本號，就需要進行一次服務的重啟更新。

然後，我對vue的打包組件進行了魔改，將他打包出來的文件

帶上了對應的版本號（版本號為hash值）

這樣子我就可以通過配置中心來控制，到底我需要使用什麼版本的vue 構建產物，vue 前端邏輯更新了，我也只需要通過配置中心去分發給服務端，而不需要重啟服務了。一舉兩得。

圖中 conf 就是配置中心，我們的server 會與conf進行一個長連接，如果conf中的配置更新了，就會通知到服務，然後服務去拉去新的bundle和manifest 來進行渲染。Ok 很棒

全民SSR

重構完，那麼再接入一個項目試試吧

首頁，好，就首頁吧

首頁跟tag 頁

其實也都差不多，沒有什麼特別的地方，唯一不同的就是 量比較大，可能一天有1000W的訪問量左右。那麼我們就在CDN上面加上一層緩存，然後在我們服務上面也加上一層緩存。破費（perfect）！~

服務端的緩存是通過文件落地來的，就是在第一個請求進來的時候 在渲染完成之後，寫一個文件到本地，然後下次訪問的時候就可以直接用這個丟這個本地文件出去，不用再次渲染了，然後通過過期時間去控制。

這裡發現了一個問題，就是每次更新 我都會將tag 和index 都進行打包，而我需要的是對項目進行單獨的打包，單獨的更新，能不能通過參數來控制我打包哪個呢，可以啊,首先先把webpack.config.js 重寫，公用部分整合，然後私有的分開寫成多個，通過package.json裡面來多配置幾個script就好啦

這樣子每次更新項目的時候，我就只需要打包對應的項目就可以了，不會因為項目接入了很多之後，打包和開發時候的熱載入變得很慢很慢。

由於接入了兩層緩存，首頁上線的時候，我們把服務從2個docker實例 擴容到了6個（docker擴容真方便），得益於緩存的優勢，服務並沒有什麼壓力

當然 首頁不可能像說的那樣，這麼隨便就上線了，需要有降級方案，那麼降級方案得益於vue的強大了.

Vue 會在瀏覽器端檢驗（data-server-render=true），是否服務端渲染了，如果服務端沒有渲染，那麼客戶端會再執行一次邏輯進行渲染。這樣子我們只要再打包的時候，將原本客戶端渲染的那個index.html 保留就可以拉，當然別忘了，再客戶端執行的時候也要運行一下asyncData裡面的方法，不然會缺少數據哦。So easy~

接下來 一級分區 二級分區也分別都接入了，中間也遇到了一些問題，不過最後都順利的解決了，後面有機會我再寫一篇文章來說一下其中遇到的問題。

再次重構

我們的項目在有序的進行著從原本靜態頁 客戶端渲染，往服務端渲染遷移的同時，我們也在公司內部進行這推廣，有幾個兄弟部門也遇到了我們之前的seo 的問題，或者是希望首屏更快等，所以很願意使用我們已經造好的輪子。可是我們的項目暫時並不具有推廣性，如果兄弟部門要使用，只有把我們的庫拷貝過去，然後把業務邏輯刪減掉，再加上自己的邏輯，成本很高，而且我們這邊一旦更新了什麼，他們都需要手動去同步，就很麻煩。

我們花了一點時間，首先，core

核心庫抽離出來，並且和日誌中心的連接方法、配置中心的連接方法等一些公用方法一起，做成一個npm包

發布到公司內部的npm 源上面，然後將client 從庫裡面獨立出來，變成前端庫，加上一個簡單的server.js，可以獨立於server 進行開發，而不用在開發的時候過分依賴node server.並且得益於配置中心，我們可以將項目分的很散，但是最終又通過配置中心，集中到同一個服務上，又回到了前後端分離上面，但是不止於前後端分離，前端獨立開發的同事，還帶上了服務端渲染，一舉兩得。設計架構如圖：

順帶，我們開發了兩個腳手架，可以很方便的創建項目，並且加好webpack的配置和package.json的配置

這樣子拆分之後，項目就變得很清真，前端開發前端vue項目，服務端有npm包可供大家使用，升級和維護都很方便，node服務也不需要一直去重啟，通過配置即可更新邏輯，熱更新。

做完之後，很多兄弟部門也都開始了接入。

壓力測試

因為每個公司的情況都不一樣，使用組件緩存，頁面緩存等等方式，都可以達到優化的目的，使其可以達到能承載項目流量的標準，我這邊說的情況是沒有任何緩存的情況下的壓測結果。

我們做過幾次不同層面的壓測，畢竟性能需要達到要求才行，記得當時出版打樣上線的時候，VUE使用的版本是2.3.x 性能不是很好，因為VUE是基於虛擬DOM（VNODE）來實現的，是CPU密集型的項目，所以在壓測的時候，CPU很快就達到了100%，TPS很低，所以我們對頁面加了緩存，像首頁這種P0級頁面都加兩層緩存，後來VUE更新到了2.4.x 性能變好了許多，但是CPU始終是一個瓶頸。如果項目複雜，組建嵌套很多的話，1C4G的伺服器，CPU打滿也就40到50的TPS就封頂了，再上去，用戶等待時間就會呈指數式上升。

我看過很多文章，拿vuessr

和字元串模板進行比較的文檔，但是他們的比較demo都很簡單，vue裡面都沒有組件嵌套，性能相比可能確實差不多，但是頁面複雜度上升，組件嵌套越多，那麼vuessr的性能就沒法再跟字元串模板進行比較了

舉個例子把，我們首頁一二級分區每天打到node上面的量跟文章的量差不多，但是文章就用了首頁三分之一的機器，機器的cpu和內存使用量差不多，因為文章項目用的是字元串模板。

總結

在整個的過程中，需要前端同學，後端同學的通力配合才行，後端api的同學需要將原本直接結合模板出數據的方法全部改成api介面，這是前後端分離的基礎。至於基礎建設，可以慢慢發展來完善，就像一開始我們構建的時候，構建出來的配置文件的版本號都是需要手動去配置到配置中心的，這很耗時，而且容易出錯，慢慢的，配置中心開放出了api介面，我們接入就很方便了，順利的實現了配置同步的自動化，只要上線的時候點一下發布就好了。

在用node做中間層的過程中，也有遇到內存泄漏，性能瓶頸等問題，後面有機會，再寫篇文章介紹吧。在這一年中，B站發展的很快，前端也有意識的去在意前端性能，讓頁面更好，更快。

腳步從未停下，我們還在路上！

嗶哩嗶哩 (゜-゜)つロ 乾杯~

推薦閱讀：