服務端渲染（ Side ，SSR）是一項可以在服務端預先生成頁面的 DOM 結構（而不是在瀏覽器端生成）的技術。SSR 的優勢就是容易 SEO，首屏加載快，對搜索引擎友好，因此 SSR 適合于重頁面內容而非交互的頁面，比如新聞站點和大型活動頁面等。SSR 對這些項目的用戶體驗有極大的提升。但世界上沒有免費的午餐，SSR 伴隨著一些不可避免的缺點，包括維護成本增加、服務器成本提升、單服務器能承受的 QPS 降低、技術復雜度提高等。

下面是通過壓測初步得到的一些 SSR 服務在接口時延不大幅增長情況下的單機 QPS 承載能力：

項目

機器配置

粗估 QPS 承載量

基準項目*

1c2g

60

next.js 基準項目*

1c2g

25

業務A 官網

4c8g

22

業務A 重構版官網

4c8g

44

業務B 歌曲回流頁

1c2g

34

注：

基準項目采用公司內部的 React 前端腳手架初始化，渲染的頁面包含 5000 個 div 的 dom 節點，通過 Node 中間件__提供服務

Next.js 基準項目通過 Next.js 腳手架初始化，渲染的頁面包含 5000 個 div 的 dom 節點，通過 next start 指令提供服務

我們可以發現在實際業務場景中 SSR 服務的單機 QPS 承載能力確實是比較低，當服務流量突增的時候會導致 SSR 集群承擔比較大的壓力。

SSR 是服務中最核心的接口，一旦掛了就會直接導致網站不可訪問，為了提升 SSR 服務的穩定性，我們需要一套通用的 SSR 降級到 CSR 的方案，來保證 SSR 集群能提供足夠大的彈性來應對突增的流量，保證核心服務的可用性，并且可以方便的在現有的 SSR 服務中快速落地。

降級方案選型Node 中間件降級

這是最便捷的一種降級方案，但是一般不建議采用通過直接在 Node 服務中增加中間件處理降級的方式來實現。原因是到當服務異常時，Node 業務進程本身就無法及時的響應請求，那相關的降級策略也就失效了。

比如，我們通過一個定時器定時獲取當前 CPU 的使用率，通過 CPU 閾值進行 CSR 降級的方案，當 Node 進程本身 CPU 負載高的時候，定時器本身可能就無法及時響應回調了。

Nginx 配置兜底

通過 Nginx 上的 配置，在 ssr 的路由響應出錯的時候進行處理，返回 csr 的結果

優：實現較為簡單，Nginx 作為最外層的兜底，可以兜住大部分異常的場景。

劣：需要一個額外的 CSR 集群用于在異常時進行響應，并且無法做更多定制化的處理。

具體實現

注：項目需要支持 CSR 和 SSR 同構

新建一個 CSR 集群，只負責響應服務的 HTML 靜態資源（或者配置一個兜底的 CDN 域名）。在 Nginx 上針對對應的服務端渲染接口的路由，配置 規則。新建一個兜底路由 @，對應的后端服務集群選擇新建的 CSR 集群/兜底的 CDN 域名。獨立網關降級

通過一個獨立的網關服務處理 CSR/SSR 流量的調度，在 SSR 服務不可用或超時情況下采用 CSR 的兜底。

請求流轉流程如下：

優：擁有最大的自由度，可以將大部分服務治理的策略（熔斷，限流等）添加到網關服務。

劣：請求鏈路額外增加了中心化的網關服務，大幅增加部署模型復雜度，同時需要引入網關服務自身額外的運維成本。

分布式網關降級

去中心化的 分布式網關與業務進程部署在同一個實例，所有的客戶端流量都通過網關接入業務服務，在網關層處理所有的非業務功能，如通用參數解析、協議轉換等。目前我們的服務都接入了 分布式網關。

優：由于業務流量都會先經過分布式網關再進入業務服務，因此在 中配置降級邏輯可以以業務無感知的方式低成本的配置部署，對業務代碼透明，無侵入，且現有服務都已經接入分布式網關，接入方式簡單搜索引擎優化，不需要單獨部署服務，不影響現有的上線流程。

劣：分布式網關的處理邏輯依然會占用業務 CPU 資源，對整體性能有一定的影響。

分布式網關降級方案

考慮到可擴展性和升級成本，最終我們選擇通過分布式網關實現通用的 SSR 降級。分布式網關支持以 的形式加載自定義的邏輯，因此我們開發并發布了一個包含降級方案的自定義 。通過在對應的服務中加載 即可完成降級方案的接入。

處理流程

其中 LB 為前置的負載均衡層，流量通過 LB 轉發到 分布式網關，再由 傳給業務服務 。

業務改造

業務改造只需要保證服務是 SSR 和 CSR 同構的，在服務降級到 CSR 的模式下可以正常的運行即可，分布式網關的接入應該對于業務是無感知的。

自適應限流

在自定義 中，我們通過一個滑動窗口動態計算 CPU 的負載來進行限流，核心目的是在流量高峰期避免單實例由于 CPU 過載而引發宕機事故。

對于 SSR 服務而言，在 CPU 超過閾值觸發自適應限流時不直接返回錯誤的狀態碼而是降級到 CSR 的 HTML 頁面，這樣可以大幅降低 CPU Load，顯著提升服務的 QPS 承載能力。

主動降級

我們支持通過全局的配置開關或者添加特定 query 的方式主動觸發 的 SSR 降級，從而支持在特殊場景下的主動降級。

MPA/SPA 模式支持

業務形態是多種多樣的，可能是多頁應用也可能是單頁應用。對于單頁應用，只需要直接降級到用戶配置的 HTML 頁面路徑即可；對于多頁應用，我們額外增加了一個路由配置文件來提供不同路由到對應的降級 HTML 的路由的映射關系。

示例的路由配置格式如下:

// ssrfallback.config.json
{
  "routes": [
    {
      "path": "^/track(/\\S)?",
      "file": "./track.html"
    },
    {
      "path": "^/album",
      "file": "./album.html"
    }
  ]
}
復制代碼

緩存

由于 會隨著業務實例的重啟而重啟，并且需要加載的降級 Html 數量是可控的，因此可以放心的對讀取的 HTML 文件添加內存緩存，減少文件 IO 的消耗。

性能測試

項目

機器配置

無降級 QPS 上限

添加降級后 QPS 上限

有效 SSR QPS

基準項目*

1c2g

60

1500

36

Next.js 基準項目

1c2g

25

1000+

14

業務A 重構版官網

4c8g

44

1000+

30

業務B 歌曲回流頁

1c2g

34

1000+

24

其中 有效 SSR QPS 指的是在觸發降級后，可以基本維持的 SSR 渲染的 QPS，大致在加壓 QPS = 500 左右的情況下測得，當加壓的 QPS 進一步上升時，有效 SSR QPS 會逐步降低，直到服務無法響應。

性能分析

以基準項目的結果為例

由于接入了自適應限流的組件，在 SSR 場景下，當 CPU 過載時可以自適應切換到 CSR 模式，降低 CPU 負載，從而保證可以處理 QPS 激增的場景，最大的 QPS 承載可以到 左右（此處只展示了到 500 的 QPS）。

觀察響應延遲可以發現整體的延遲水平較低，只有在剛觸發自適應限流的一段時間內由于 CPU 壓力會有一段時間較高的延遲，后續可以平穩的保持正常的響應。

通過打點統計，SSR 非降級請求的 QPS 可以基本穩定在 30+，在高負載的情況下，依然可以充分利用實例的性能，完成一定程度的 SSR 渲染請求，而不會全量降級為 CSR。

有效 SSR QPS，隨著加壓 QPS 逐步增加會有一定降低，發壓 QPS 穩定后，SSR 的 QPS 也基本穩定

降級 QPS，隨著壓測 QPS 升高逐步升高

其中 99.6% 以上的請求都能在 800ms 之內返回。

小結

為了提升 SSR 服務的穩定性搜索引擎優化，我們選擇在分布式網關上實現了 SSR 降級的邏輯來提供通用的基于分布式網關的 SSR 降級能力。通過在多個業務場景的 SSR 服務的實踐和性能測試，本方案可以保證 SSR 集群在流量突增的情況下，能夠基于當前的 CPU 資源動態的降級一定比例的請求到 CSR，大幅提升 SSR 服務集群的承載能力，并且對于業務的改造成本較低，方便快速落地接入。