React同構與極致的效能優化

注：本文為第12屆D2前端技術論壇《打造高可靠與高效能的React同構解決方案》分享內容，已經過資料脫敏處理。

前言

隨著React的興起, 結合Node直出的效能優勢和React的元件化，React同構已然成為趨勢之一。享受技術福利的同時，直面技術挑戰，在複雜場景下，挑戰10倍以上極致的效能優化。

什麼是同構？

一套程式碼既可以在服務端執行又可以在客戶端執行，這就是同構應用。簡而言之, 就是服務端直出和客戶端渲染的組合, 能夠充分結合兩者的優勢，並有效避免兩者的不足。

為什麼同構？

效能: 通過Node直出, 將傳統的三次序列http請求簡化成一次http請求，降低首屏渲染時間
SEO: 服務端渲染對搜尋引擎的爬取有著天然的優勢，雖然阿里電商體系對SEO需求並不強，但隨著國際化的推進, 越來越多的國際業務加入阿里大家庭，很多的業務依賴Google等搜尋引擎的流量匯入，比如Lazada.
相容性: 部分展示類頁面能夠有效規避客戶端相容性問題，比如白屏。

效能資料

效能是一個綜合性的問題, 不能簡單地斷言同構應用一定比非同構應用效能好，只能說合適的場景加上合理的運用，同構應用確實能帶來一定的效能提升, 先來看一個線上的案例。

通常來說，網路狀況越差，同構的優勢越明顯，下圖是在不同網路狀況下首屏渲染時間的一組對比

線上案例

近兩年，無論是業界還是阿里內部都湧現了大量同構實踐, 業界比較有影響力的包括Facebook, Quora, Medium, Twitter, Airbnb, Walmart、手Q以及QQ興趣部落等
阿里內部也有大量的應用，僅列舉部分beidou開發組做過技術支援的專案
- 阿里雲 – 大資料地產
- 釘釘 – 企業主頁
- 釘釘 – 釘釘日誌和審批模板市場
- 菜鳥 – 物流大市場
- 雲零售 – 店掌櫃
- Lazada – PDP
- 國際事業部 – AGLA
- AILab – 行業解決方案
- AILab – 智慧硬體平臺
- AILab – AliGenie開放平臺
- AILab – AR官網
- ICBU – ICBU店鋪
- 業務平臺 – 門店評價
- 國際UED – 資料運營
- 國際UED – 知之
- 國際UED – 探花
- 國際UED – Nuke官網及過程管理
- 國際UED – 會議記錄，實時翻譯
- 國際UED – LBS資料地圖
- 國際UED – 數探
- 國際UED – 微策
- 國際UED – shuttle
- 國際UED – fie portal
- …

業界生態

react-server: React服務端渲染框架
next.js: 輕量級的同構框架
beidou: 阿里自己的同構框架，基於eggjs, 定位是企業級同構框架

除了開源框架，底層方面React16重構了SSR, react-router提供了更加友好的SSR支援等等, 從某種程度上來說，同構也是一種趨勢，至少是方向之一。

思考與實現

同構的出發點不是 “為了做同構，所以做了”, 而是迴歸業務，去解決業務場景中SEO、首屏效能、使用者體驗等問題，驅動我們去尋找可用的解決方案。在這樣的場景下，除了同構本身，我們還需要考慮的是:

高效能的 Node Server
可靠的同構渲染服務
可控的運維成本
可複用的解決方案
…

簡單歸納就是, 我們需要一個企業級的同構渲染解決方案。

我們是怎麼做的？

基於 eggjs 加入可拔插的同構能力

beidou-plugin-react 作為原有MVC架構中, view 層的替換, 使用 React 元件作為檢視層模板, 可以直接渲染 React Component 並輸出給客戶端
beidou-plugin-webpack 整合 Webpack 到框架中, 在開發階段, 提供程式碼的編譯和打包服務
beidou-plugin-isomorphic 服務端的 React 執行時: babel-register polyfill 注入: 環境變數, BOM等非js檔案解析: css, images, fonts…
服務端支援css modules
自動路由: 純靜態頁面無需編寫任何服務端程式碼，像寫純前端頁面一樣簡單
…

這裡不再贅述具體如何實現，有興趣的讀者可以閱讀我們的開源同構框架beidou — https://github.com/alibaba/beidou

熱點問題

任何一種技術都有其適用場景和侷限性, 同構也不例外，以下試舉一二，以做拋磚引玉.

記憶體洩漏
效能瓶頸
…

記憶體洩漏不是同構應用所特有的，理論上所有服務端應用都可能記憶體洩漏，但同構應用是“高危群體”, 具體如何解決請參考本人的《Node應用記憶體洩漏分析方法論與實戰》, 接下來重點剖析下效能優化。

極致的效能優化

前面也提到了，同構應用並不一定就比非同構應用效能好，影響效能的因素實在太多了，再來看一組資料

上圖是基於Node v8.9.1 和 React@15.5.4, 開4個程式採集到的資料, X軸是最終生成頁面節點數量，Y軸紅色的線表示RT(包括渲染時間和網路時間), 綠色的柱子表示QPS. 可以看出來:

隨著頁面節點的增多渲染時間可能變得很長，QPS下降非常迅速。在頁面節點超過3000左右的時候，QPS接近個位數了，而且實際頁面中可能包含較複雜的邏輯以及不友好的寫法，情況可能會更糟。

順帶提一下, 筆者取樣了淘寶首頁和淘寶某詳情頁以及Lazada某詳情頁，頁面節點數分別是2620、2467和3701. 大部分情況下，頁面節點數低於1000，比如菜鳥物流市場首頁看起來內容不少，其實節點數是775.

那針對3000節點以上的頁面，我們該怎麼做呢？筆者總結了以下策略並重點闡述其中一兩點：

採用編譯後的React版本: 根據Sasha Aickin的部落格，React15在Node4、Node6、Node8下，採用編譯後的版本效能相比未編譯版本分別提升了2.36倍、3倍、3.85倍
模組拆分: 模組拆分有利於併發渲染，目前ICBU店鋪裝修採用的就是這種方式
模組級別快取: 頁面中某些模組其實是很適合快取的，比如Lazada詳情頁中節點數雖然高達3701, 但其實頁頭部分就佔比55.5%，頁尾佔比3.5%，而頁頭頁尾是常年不變的.
元件級快取：最小粒度的快取單位了，效能提升依賴於快取的範圍和命中率，運用得當，可能帶來非常大的效能提升。參考walmartlabs
採用hsf代替http對外提供服務: hsf的網路消耗遠低於http, 在店鋪同構實踐中，改用hsf, java端呼叫Node端的耗時縮短了一半.
部分模組客戶端渲染(對SEO無用的部分): 直接降低SSR部分的複雜度
智慧降級: 當流量暴增，接近或超過閾值時，會直接導致服務的RT快速上升。可以實時監測CPU和記憶體的使用率，超過一定的比例自動降級為客戶端渲染，降低服務端壓力，CPU和記憶體恢復常態時，自動切回服務端渲染。
採用Node8: 同樣在店鋪實踐中，採用Node8相比Node6, 渲染時間從28ms降低到了18ms, 提升幅度為36%.
採用最新版React16: facebook官方資料, 在Node8下，React16相比編譯後的react15仍有3.8倍提升，相比未編譯的React15更是有數量級的提升。

元件級快取

如果說效能優化有”萬能”的招式，那一定是快取, 從Nigix快取到模組級快取到元件級快取，其中最讓人興奮的就是元件級快取，讓我們一起來看看如何實現

攔截React的渲染邏輯，業界主要有三種實現方式
- Fork一份React, 暴力加入快取邏輯, 代表庫是react-dom-stream, 雖然這個庫的人氣很高，但筆者還是反對這種實現方式的。
- 通過require hook攔截instantiateReactComponent的載入並注入快取邏輯，參考react-ssr-optimization
- 擴充套件ReactCompositeComponent的mountComponent方法，參考electrode-react-ssr-cachin
注入快取邏輯, 程式碼如下

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

const ReactCompositeComponent = require("react/lib/ReactCompositeComponent");

ReactCompositeComponent.Mixin._mountComponent = ReactCompositeComponent.Mixin.mountComponent;

ReactCompositeComponent.Mixin.mountComponent = function(rootID, transaction, context) {

const hashKey = generateHashKey(this._currentElement.props);

if (cacheStorage.hasEntry(hashKey)) {

// 命中快取則直接返回快取結果

return cacheStorage.getEntry(hashKey);

} else {

// 若未命中，則呼叫react的mountComponent渲染元件，並快取結果

const html = this._mountComponent(rootID, transaction, context);

cacheStorage.addEntry(hashKey, html);

return html;

}

};

設定最大快取和快取更新策略

1

2

3

4

lruCacheSettings: {

max: 500, // The maximum size of the cache

maxAge: 1000 * 5 // The maximum age in milliseconds

}

上述快取邏輯是基於屬性的，能覆蓋大部分的應用場景，但有一個要求，屬性值必須可列舉且可選項很少. 請看下面的場景。

淘寶某頁面上有大量的商品，而淘寶的商品又何止百萬，就算某個被快取，下次被命中的可能性依然微乎其微。那如何解決這個問題？聰明的讀者可能已經看出來了，雖然每個商品最終渲染的結果千變萬化，但結構始終是一致的，因此結構是可以快取的。

要實現結構的快取，需要在上述邏輯上額外新增三步。

生成中間結構：
- 以元件${price}為例，將變數price以佔位符${price}代替set(price, "${price}"), 再呼叫react原生的mountComponent方法則可以生成中間結構
  ${price}
快取中間結構
生成最終元件

以上就是元件級快取的實現方式, 特別要提醒的是快取是把雙刃劍，運用不當可能會引發記憶體洩漏以及資料的不一致。

React16 SSR

FB在9.26釋出了React16正式版，之前萬眾期待的SSR效能提升沒有讓大家失望, 引用React核心開發Sasha Aickin的對比圖

筆者拿之前的應用升級到React16, 對比下3909節點，RT從295ms降到了51ms, QPS從9提升到了44, 提升非常明顯。

實戰

接下來通過一個例子，展示如何一步步地提升效能。程式碼倉庫 — https://github.com/alibaba/beidou/

10倍以上效能提升

首先構造一個非常複雜的頁面, 頁面節點數是3342, 對比之下，淘寶首頁首屏的頁面節點數是831, 非同步充分載入之後(懶載入完成),整個頁面節點數為3049. 注：淘寶頁面為動態頁面，每次取樣可能會有差異。

初始平均渲染時間為295.75ms(Node6.92, React15.6.2), 注: 圖中有296.50ms,317.25ms,297.25ms,295.75ms四個平均值，是因為開啟了四個程式，取樣最後一個，下同。

啟用babel效能加速外掛, 平均渲染時間為219.00ms

採用Node8.9.1(或更新版本)平均渲染時間為207ms

採用production模式平均渲染時間為81.75ms

部分內容客戶端渲染，平均渲染時間為44.63ms

部分內容元件級別cache,平均渲染時間為22.65ms

採用React16(或更新版本)，平均渲染時間為5.17ms

結合React16和部分客戶端渲染，平均渲染時間為2.68ms

至此，服務端渲染時間已經最初的295.75ms降低到了2.68ms，提升了超過100倍。

萬變不離其宗

借用《功夫》中的一句經典臺詞天下武功，無堅不破，唯快不破，同樣的，隨著時間的推移，上面這些策略策略遲早會被破，比如react16 ssr重構之後，之前的元件級別快取邏輯不再有效。另外，可能由於架構設計/技術選型根本就使不上勁，比如react16是今年9月26才正式發版，很多第三方元件還沒來得及升級，如果應用中有些元件強依賴於react15或者更早的版本，可能根本就沒法利用react16的效能優勢。

那麼有沒有一種萬能的辦法，能夠做到唯快不破呢？

答案是：有的。只有掌握了方法論，才能在不斷變化中，找到適合自己應用的效能優化策略。

具體的方法論，請參考本人的另外一篇文章《唯快不破，讓nodejs再快一點》