[原文：Operationalizing Node.js for Server Side Rendering](https://medium.com/airbnb-engineering/operationalizing-node-js-for-server-side-rendering-c5ba718acfc9)

在 Airbnb，我們花了數年時間將所有前端程式碼穩定地遷移到一致的架構中，在該架構中，整個網頁都被編寫為 React 元件的層次結構，其中包含來自我們 API 的資料。 Ruby on Rails 在將 Web 連線到瀏覽器方面所扮演的角色每天都在減少。事實上，很快我們將過渡到一項新服務，該服務將完全在 Node.js 中提供完全形成的、伺服器呈現的網頁。此服務將為所有 Airbnb 產品呈現大部分 HTML。這個渲染引擎不同於我們執行的大多數後端服務，因為它不是用 Ruby 或 Java 編寫的。但它也不同於我們的心智模型和通用工具所圍繞的那種常見的 I/O 密集型 Node.js 服務。

當您想到 Node.js 時，您會設想您的高度非同步應用程式同時高效地為數百或數千個連線提供服務。您的服務正在從整個城鎮提取資料，並進行應用輕量級處理，以使其適合眾多客戶。也許您正在處理一大堆長期存在的 WebSocket 連線。您對非常適合該任務的輕量級併發模型感到滿意和自信。

伺服器端渲染 (SSR) 打破了導致該願景的假設。它是計算密集型的。 Node.js 中的使用者程式碼在單個執行緒中執行，因此對於計算操作（與 I/O 相對），您可以併發執行它們，但不能並行執行。 Node.js 能夠並行處理大量非同步 I/O，但會遇到計算限制。隨著請求的計算部分相對於 I/O 的增加，併發請求將對延遲產生越來越大的影響，因為 CPU 爭用。

考慮 Promise.all([fn1, fn2])。如果 fn1 或 fn2 是由 I/O 解析的承諾，您可以像這樣實現並行性：

![](https://img-blog.csdnimg.cn/img_convert/c180c8e54d9b4ecf49c5922fe23ff625.png)

如果 fn1 和 fn2 是計算的，它們將改為這樣執行：

![](https://img-blog.csdnimg.cn/img_convert/b03f5bd2b0bbad3b08d8a3d1d4291969.png)

一個操作必須等待另一個完成才能執行，因為只有一個執行執行緒。

對於伺服器端渲染，當伺服器程式處理多個併發請求時會出現這種情況。 併發請求將被正在處理的其他請求延遲：

![](https://img-blog.csdnimg.cn/img_convert/8a59f8f270950087ddeb5db58c5e6e5f.png)

在實踐中，請求通常由許多不同的非同步階段組成，即使仍然主要是計算。 這可能導致更糟糕的交織。 如果我們的請求由一個像 renderPromise().then(out => formatResponsePromise(out)).then(body => res.send(body)) 這樣的鏈組成，我們可以有像這樣的請求交錯：

![](https://img-blog.csdnimg.cn/img_convert/499a18017d130145bed56f20f89c30d0.png)

在這種情況下，兩個請求最終都會花費兩倍的時間。隨著併發性的增加，這個問題變得更糟。

此外，SSR 的共同目標之一是能夠在客戶端和伺服器上使用相同或相似的程式碼。這些環境之間的一個很大區別是客戶端上下文字質上是單租戶，而伺服器上下文是多租戶的。在客戶端輕鬆工作的技術（如單例或其他全域性狀態）將導致伺服器上併發請求負載下的錯誤、資料洩漏和一般混亂。
這兩個問題只會成為併發問題。在較低的負載水平下或在您的開發環境的舒適單一租戶中，一切通常都能正常工作。
這導致了與 Node 應用程式的規範示例完全不同的情況。我們使用 JavaScript 執行時是因為它的庫支援和瀏覽器特性，而不是它的併發模型。在這個應用程式中，非同步併發模型強加了它的所有成本，沒有或只有很少的好處。

# 一些經驗分享

使用者傳送請求到我們的主要 Rails 應用程式 Monorail，它將希望在任何給定頁面上呈現的 React 元件的 props 拼湊在一起，並使用這些 props 和元件名稱向 Hypernova 發出請求。 Hypernova 使用 props 渲染元件以生成 HTML 以返回到 Monorail，然後將其嵌入到頁面模板中並將整個內容傳送回客戶端。

![](https://img-blog.csdnimg.cn/img_convert/cc47dd2081306a42cd068f91ce6ef2d0.png)

![](https://img-blog.csdnimg.cn/img_convert/8327e8d01f60ba4beb53d549125e9f3d.png)

在 SSR 渲染失敗（由於錯誤或超時）的情況下，回退是將元件及其道具嵌入頁面而不渲染 HTML，允許它們（希望）被客戶端成功渲染。 這導致我們將 SSR 視為一種可選的依賴項，並且我們能夠容忍一定數量的超時和失敗。 我們將呼叫超時設定為大約在我們調整值時觀察到的值。不出所料，我們以略低於 5% 的超時基線執行。

在日常流量負載高峰期進行部署時，我們會看到高達 40% 的 SSR 請求發生超時。類似 BadRequestError: Request aborted on deploys 的這些錯誤，掩蓋了所有其他應用程式/編碼錯誤。

我們曾將延遲歸咎於啟動延遲，而延遲實際上是由併發請求相互等待以使用 CPU 造成的。 從我們的效能指標來看，由於其他正在執行的請求而等待執行所花費的時間與執行請求所花費的時間無法區分。 這也意味著併發導致的延遲增加看起來與新程式碼路徑或功能導致的延遲增加相同——實際上增加了任何單個請求的成本。

BadRequestError: Request aborted 錯誤也變得越來越明顯，不能用一般的慢啟動效能來解釋。 該錯誤來自正文解析器，特別是在客戶端在伺服器能夠完全讀取請求正文之前中止請求的情況下發生。 客戶端放棄並關閉連線，帶走我們繼續處理請求所需的寶貴資料。 發生這種情況的可能性要大得多，因為我們開始處理一個請求，然後我們的事件迴圈被另一個請求的渲染阻塞，然後從我們被中斷的地方返回完成，卻發現客戶端已經離開了。

![](https://img-blog.csdnimg.cn/img_convert/d00e77ea4a5aaec837c1d1c9c0bc24a9.png)

我們決定透過使用我們擁有大量現有操作經驗的兩個現成元件來解決這個問題：反向代理 (nginx) 和負載均衡器 (haproxy)。

# Reverse Proxying and Load Balancing

為了利用我們的 SSR 伺服器上存在的多個 CPU 核心，我們透過內建的 Node.js 叢集模組執行多個 SSR 程式。 由於這些是獨立的程式，我們能夠並行處理併發請求。

![](https://img-blog.csdnimg.cn/img_convert/31f14bc0b8219a975fbff4b62cd38125.png)

這裡的問題是每個節點程式在請求的整個持續時間內都被有效佔用，包括從客戶端讀取請求正文。

雖然我們可以在單個程式中並行讀取多個請求，但這會導致在進行渲染時計算操作的交錯。

節點程式的使用與客戶端和網路的速度耦合。

解決方案是使用緩衝反向代理來處理與客戶端的通訊。 為此，我們使用 nginx。 Nginx 將來自客戶端的請求讀入緩衝區，並在完全讀取後將完整請求傳遞給節點伺服器。

這種傳輸透過環回或 unix 域套接字在機器上本地發生，這比機器之間的通訊更快、更可靠。

![](https://img-blog.csdnimg.cn/img_convert/e8c3552518c8ba9f505e2c229af4352c.png)

透過 nginx 處理讀取請求，我們能夠實現節點程式的更高利用率。

![](https://img-blog.csdnimg.cn/img_convert/fbd88e87c64b2ec8c0fe0544e03afc28.png)

# 總結

伺服器端渲染代表與 Node.js 擅長的規範的、主要是 I/O 工作負載不同的工作負載。瞭解異常行為的原因使我們能夠使用我們擁有現有操作經驗的現成元件來解決它。

非同步渲染仍然存在資源爭用。非同步渲染解決程式或瀏覽器的響應問題，但不解決並行性或延遲問題。 這篇翻譯的博文重點介紹的是純計算工作負載的簡單模型。對於 IO 和計算的混合工作負載，請求併發會增加延遲，但具有允許更高吞吐量的好處。

部署 Node.js 應用以完成伺服器端渲染 Server Side Rendering 的效能調優

相關文章