程式前沿 幫助程式設計師解決問題，增加專業技能，提升個人能力與未來世界競爭力。

React同構與極致的效能優化

React同構與極致的效能優化

                               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應用記憶體洩漏分析方法論與實戰》（https://github.com/alibaba/beidou/blob/master/packages/beidou-docs/articles/node-memory-leak.md），接下來重點剖析下效能優化。


極致的效能優化

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

上圖是基於Node v8.9.1 和 [email protected], 開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（https://medium.com/walmartlabs/reactjs-ssr-profiling-and-caching-5d8e9e49240c）

  • 採用hsf代替http對外提供服務: hsf的網路消耗遠低於http, 在店鋪同構實踐中，改用hsf, java端呼叫Node端的耗時縮短了一半。

  • 部分模組客戶端渲染(對SEO無用的部分): 直接降低SSR部分的複雜度

  • 智慧降級: 當流量暴增，接近或超過閾值時，會直接導致服務的RT快速上升。可以實時監測CPU和記憶體的使用率，超過一定的比例自動降級為客戶端渲染，降低服務端壓力，CPU和記憶體恢復常態時，自動切回服務端渲染。

  • 採用Node8: 同樣在店鋪實踐中，採用Node8相比Node6, 渲染時間從28ms降低到了18ms, 提升幅度為36%.

  • 採用最新版React16: facebook官方資料（https://reactjs.org/blog/2017/09/26/react-v16.0.html#better-server-side-rendering），在Node8下，React16相比編譯後的react15仍有3.8倍提升，相比未編譯的React15更是有數量級的提升。


元件級快取

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

  • 攔截React的渲染邏輯，業界主要有三種實現方式

    • Fork一份React, 暴力加入快取邏輯, 代表庫是react-dom-stream,
      雖然這個庫的人氣很高，但筆者還是反對這種實現方式的。

    • 通過require hook攔截instantiateReactComponent的載入並注入快取邏輯，參考react-ssr-optimization（https://github.com/aickin/react-dom-stream）

    • 擴充套件ReactCompositeComponent的mountComponent方法，參考electrode-react-ssr-cachin（https://github.com/electrode-io/electrode-react-ssr-caching/blob/master/lib/ssr-caching.js#L148-L161）

  • 注入快取邏輯, 程式碼如下

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;
  }
};

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

lruCacheSettings: {
      max: 500,  // The maximum size of the cache
      maxAge: 1000 * 5 // The maximum age in milliseconds
  }

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

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

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

  • 生成中間結構：

    • 以元件<Price>${price}</Price>為例，將變數price以佔位符${price}代替set(price,
      “${price}”), 再呼叫react原生的mountComponent方法則可以生成中間結構<div>${price}</div

  • 快取中間結構

  • 生成最終元件

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


React16 SSR

  • FB在9.26釋出了React16正式版，之前萬眾期待的SSR效能提升（https://hackernoon.com/whats-new-with-server-side-rendering-in-react-16-9b0d78585d67）沒有讓大家失望,
    引用React核心開發Sasha Aickin的對比圖：

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

實戰

接下來通過一個例子，展示如何一步步地提升效能。程式碼倉庫（https://github.com/alibaba/beidou/tree/master/examples/performance）
— 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倍。


更多效能策略

其實除了上述應用的策略，還有其它的策略，比如：

  • 採用Async, 有資料稱效能提升30%, 筆者試了下，未見明顯提升。應該是經過了babel的編譯，最終沒有發揮出Async的優勢，這是因為beidou框架在服務端要支援import等ES6的寫法以及支援React的JSX語法。其實也非常簡單，直接縮小babel的編譯範圍，在beidou框架中是可以自己定義的。

  • 降低React元件的巢狀層級。試驗資料，同樣的頁面節點數，服務端渲染時間和元件的巢狀層級是線性正相關的。

  • 熱點快取 …


萬變不離其宗

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

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

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

具體的方法論，請參考本人的另外一篇文章《唯快不破，讓nodejs再快一點》（https://github.com/alibaba/beidou/blob/master/packages/beidou-docs/articles/node-performance-optimization.md）。

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

出處：https://github.com/alibaba/beidou/blob/master/packages/beidou-docs/articles/high-performance-isomorphic-app.md

版權申明：內容來源網路，版權歸原創者所有。除非無法確認，我們都會標明作者及出處，如有侵權煩請告知，我們會立即刪除並表示歉意。謝謝。

-END-