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-