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

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

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

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

再次重構

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

我們花了一點時間，首先，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站發展的很快，前端也有意識的去在意前端性能，讓頁面更好，更快。

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

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