2017年即將過去了，總結一下B站的前端進階之路
過去的開發模式中，我們採用了以後端為主的 MVC 架構方式。具體來說，每次專案評審後，前後端會先一起約定好介面，之後分別進行開發，開發完，前端需要把頁面提供給後端，後端配置上資料，然後返回出來。正式基於這樣的開發模式，導致了總工作量的增加，同時溝通和聯調成本的消耗也十分顯著。
前後端分離
為了擺脫這種前後端過分依賴的情況，（其實前端也不想每次修改或者釋出都要後端這邊釋出，後端也不想每次前端只改個標題，都要釋出一下,影響服務的穩定性），那麼先從前後端分離開始吧~
前後端分離，最基本的兩種模式，有中間層和沒有中間層。
第一種，沒有web中間層就很簡單，提供一個html模板放到靜態資源機上面，html模板裡面引用了所需的js和css ,訪問頁面的時候 把這個靜態模板返回給使用者，然後執行js 在瀏覽器端通過ajax請求api拿到資料，渲染頁面。
第二種，有node中間層，隨著2009年，Node的橫空出世，把前端慢慢的推向了後端，有了node之後，JavaScript可以做更多的事情。
B站，一開始做前後端分離的時候，也確實按照第一種方式去做的,現在還有一些頁面仍然是這種模式,例如:www.bilibili.com/account/his… (可檢視網頁原始碼)。對於不需要seo的頁面來說，是一個不錯的方式。前端開發完成之後，通過webpack打包出對應的js和css 上傳到cdn上面，然後將webpack打包出來的 引用了對應的資源的html檔案 上傳到一臺專門的靜態機上面，然後運維配置路由 將頁面流量導過去就好了。後端的同學只需要提供對應的api介面就可以。前後端分開維護，自己按照自己的節奏走，降低了頁面與服務的耦合度
這種方式確實是一種很快能夠進行前後端分離的方法。我們花了一段時間，在pc端使用vue 進行重構，移動端H5端 用react 進行了重構。 進度很快，但是也慢慢展現出了弊端。
首屏的時候，因為他要等待資源載入完成，然後再進行渲染，會導致了首屏有白屏，如果是單個頁面還好，如果是spa應用 那麼 他的載入時間就會變得很長，白屏時間會很影響使用者體驗，再有就是由於國內的搜尋公司 對於spa 應用沒有很好的相容，導致了客戶端渲染會對seo非常的不友好，有seo 需求的頁面就很迫切的需要服務端渲染。
那麼，依賴node 進行服務端渲染就被提上了日程。
選型
首先進行node 框架的選型，市面上主流框架有三種，hapi express koa ,還有一些是經過一些封裝和定製的框架，例如 eggjs等
一開始我就把eggjs 排除在外了，第一 因為eggjs,的功能很強大，有很多功能，多到有些根本用不著，從而導致了他會重 不輕量級，第二，eggjs對於我來說是個黑盒，如果有什麼問題，我解決起來將會花費很長的時間。（但是有很多地方 我還是借鑑了eggjs的，畢竟 很強大）
然後剩下的三種框架，express的使用相對簡單，文件也比較多 比較全面，所以我就選擇了express(後來還是重構掉了 = =!)
然後是前端框架的選型 因為前端框架主流的有很多，ng r v 等等，我站在用的是react和vue, 他們有個優勢就是可以進行前後端同構，一樣的邏輯不用寫兩份，很棒
由於之前前後端分離的時候，pc 上面已經再用vue 進行了重構，所以自然，這次服務端渲染也建立在vue上面 用的是vue ssr (這也為我後面的一個想法埋下了伏筆)
首先 我們選擇一個簡單的頁面來做打樣，就用tag頁吧（被神選中的孩子：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, {
... })
複製程式碼構建配置也是用的推薦的配置（參考：ssr.vuejs.org/zh/build-co… ）
簡單來說，就是提供兩個入口，一個entry-client.js,主要是客戶端的執行入口， 打包出來的是客戶端的引用程式碼集合（manifest），另外一個是entry-server.js 打包出來的是服務端執行的邏輯,整合到了bundle.json裡面。然後傳給上面的createBundleRender方法就可以了
對於server資料夾裡面的邏輯就非常簡單了，core裡面是啟動專案的一些express的核心程式碼 路由註冊什麼的邏輯，值得一說的是，這邊的路由，借鑑了eggjs的路由註冊方式，稍微做了一點修改，用的是配置化的方式
這邊還有一個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 前端邏輯更新了，我也只需要通過配置中心去分發給服務端，而不需要重啟服務了。一舉兩得。
全民SSR
重構完，那麼再接入一個專案試試吧
首頁，好，就首頁吧
首頁跟tag 頁 其實也都差不多，沒有什麼特別的地方，唯一不同的就是 量比較大，可能一天有千萬級的訪問量左右。那麼我們就在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.並且得益於配置中心，我們可以將專案分的很散，但是最終又通過配置中心，集中到同一個服務上，又回到了前後端分離上面，但是不止於前後端分離，前端獨立開發的同事，還帶上了服務端渲染，一舉兩得。設計架構如圖：
這樣子拆分之後，專案就變得很清真，前端開發前端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站發展的很快，前端也有意識的去在意前端效能，讓頁面更好，更快。
腳步從未停下，我們還在路上！