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

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

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

接下來(lái) 一級(jí)分區(qū) 二級(jí)分區(qū)也分別都接入了，中間也遇到了一些問(wèn)題，不過(guò)最后都順利的解決了，后面有機(jī)會(huì)我再寫(xiě)一篇文章來(lái)說(shuō)一下其中遇到的問(wèn)題。

再次重構(gòu)

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

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

拆分

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

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

做完之后，很多兄弟部門(mén)也都開(kāi)始了接入。

壓力測(cè)試

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

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

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

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

總結(jié)

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

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

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

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