由于接入了兩層緩存，首頁上線的時候，我們把服務(wù)從2個docker實例 擴(kuò)容到了6個（docker擴(kuò)容真方便），得益于緩存的優(yōu)勢，服務(wù)并沒有什么壓力

當(dāng)然 首頁不可能像說的那樣，這么隨便就上線了，需要有降級方案，那么降級方案得益于vue的強(qiáng)大了.

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

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

再次重構(gòu)

我們的項目在有序的進(jìn)行著從原本靜態(tài)頁 客戶端渲染，往服務(wù)端渲染遷移的同時，我們也在公司內(nèi)部進(jìn)行這推廣，有幾個兄弟部門也遇到了我們之前的seo 的問題，或者是希望首屏更快等，所以很愿意使用我們已經(jīng)造好的輪子?？墒俏覀兊捻椖繒簳r并不具有推廣性，如果兄弟部門要使用，只有把我們的庫拷貝過去，然后把業(yè)務(wù)邏輯刪減掉，再加上自己的邏輯，成本很高，而且我們這邊一旦更新了什么，他們都需要手動去同步，就很麻煩。

我們花了一點時間，首先，core核心庫抽離出來，并且和日志中心的連接方法、配置中心的連接方法等一些公用方法一起，做成一個npm包發(fā)布到公司內(nèi)部的npm 源上面，然后將client 從庫里面獨立出來，變成前端庫，加上一個簡單的server.js，可以獨立于server 進(jìn)行開發(fā)，而不用在開發(fā)的時候過分依賴node server.并且得益于配置中心，我們可以將項目分的很散，但是最終又通過配置中心，集中到同一個服務(wù)上，又回到了前后端分離上面，但是不止于前后端分離，前端獨立開發(fā)的同事，還帶上了服務(wù)端渲染，一舉兩得。設(shè)計架構(gòu)如圖：

拆分

順帶，我們開發(fā)了兩個腳手架，可以很方便的創(chuàng)建項目，并且加好webpack的配置和package.json的配置

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

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

壓力測試

因為每個公司的情況都不一樣，使用組件緩存，頁面緩存等等方式，都可以達(dá)到優(yōu)化的目的，使其可以達(dá)到能承載項目流量的標(biāo)準(zhǔn)，我這邊說的情況是沒有任何緩存的情況下的壓測結(jié)果。

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

我看過很多文章，拿vuessr和字符串模板進(jìn)行比較的文檔，但是他們的比較demo都很簡單，vue里面都沒有組件嵌套，性能相比可能確實差不多，但是頁面復(fù)雜度上升，組件嵌套越多，那么vuessr的性能就沒法再跟字符串模板進(jìn)行比較了。

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

總結(jié)

在整個的過程中，需要前端同學(xué)，后端同學(xué)的通力配合才行，后端api的同學(xué)需要將原本直接結(jié)合模板出數(shù)據(jù)的方法全部改成api接口，這是前后端分離的基礎(chǔ)。至于基礎(chǔ)建設(shè)，可以慢慢發(fā)展來完善，就像一開始我們構(gòu)建的時候，構(gòu)建出來的配置文件的版本號都是需要手動去配置到配置中心的，這很耗時，而且容易出錯，慢慢的，配置中心開放出了api接口，我們接入就很方便了，順利的實現(xiàn)了配置同步的自動化，只要上線的時候點一下發(fā)布就好了。

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

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

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