邊緣計算聽說過嗎？淘寶用它提升了69%的首屏性能！

作者| 趙亞兵(蒂夫)

出品|阿里巴巴新零售淘系技術部

前情

在開始正題之前，我先講一個內容詳情的業務場景和其面臨的性能問題。

▐ 業務特點

圖文內容詳情業務本身有三個比較大的特點：

內容量大，幾十億的內容量，並且每天還在瘋狂增長；
流量大，爲了支撐這麼大的業務，需要很多服務器成本；
內容數據極具靜態化，頁面參考如下，除了藍色標識的數據，其他數據很少會改動；

那我們看這麼一個頁面的加載和渲染過程大概是什麼樣的？

▐ 總結問題

從上面的流程可以看出幾個問題：

首屏渲染依賴多次請求，導致首屏渲染性能差，尤其是低端機
服務端壓力大，每次請求都需要請求到服務端，對服務器也會帶來非常大的壓力
內容重複渲染，同樣一篇內容每個人看到都一樣，但是渲染結果又無法共享

▐ 大膽思考

這時候我們要結合業務本身的特性進行一些大膽的思考：

研發時預渲染

首先想到的是在研發過程中就對內容進行預渲染並存儲起來，但是這個方案很快被 pass 了，有兩個主要原因：

內容量太大：內容數量特別大，並且一篇內容在不同的場景（上百）還會展示出不同的風格，全部靜態化存儲 CDN 資源浪費嚴重
更新成本大：內容會被達人修改，或者一些打擦邊球的內容需要儘快下線

按需渲染結果靜態化

既然數據絕大部分是靜態化的，爲什麼不能把用戶訪問時靜態數據和代碼渲染後的結果進行靜態化，這樣不是省去了 renderToHTML 的過程了嗎？，如下圖所示

那講到這裏，我們首先想到的是通過 SSR renderToHTMLString，然後把渲染後的結果進行緩存，這樣訪問到相同內容的請求可以直接將緩存結果返回，那這樣有什麼好處呢：

減少重複渲染，提升首屏性能
降低接口服務的壓力
基於訪問存儲，避免資源浪費

但是同時也帶來了其他的問題：

SSR 應用服務器距離用戶遠帶來的白屏時間延長
SSR 本身的壓力也會提升，因爲這樣意味着每一個用戶請求都要經過 SSR（雖然可以走緩存）
緩存數據存儲的問題，存哪裏，內存肯定不滿足需求，因爲剛開始就講到了內容量特別大，這時候要藉助於其他的一些快速存儲的雲服務，顯得特別複雜

這時候我們就在想，如果能夠將渲染的結果或者渲染的過程放在 CDN 上就好了，因爲 CDN 節點比較多，並且在世界範圍部署廣泛，所以我們嘗試着將 SSR 渲染的結果存儲在 CDN 上，但是隨之帶來另外一些問題：

SSR 服務器出錯了怎麼辦，現在 CDN 是一種配置生效系統，如下圖所示，我們上文說到了圖文詳情的流量特別大，這也就意味着各種異常情況都要考慮，像 SSR 服務器宕機帶來的風險我們也必須有降級方案，保障不影響用戶

對於兩種特殊場景需要及時更新緩存：擦邊球內容要能夠及時下線，頁面代碼更新要能夠批量更新緩存，目前通過 CDN 的配置項是解決不了這些問題的

這時我們正好了解到了 CDN 正在推廣一種邊緣計算的能力（EdgeRoutine，下面會做簡單的介紹），簡單點理解就是可以在 CDN 請求返回結果之前加上你的自定義腳本，並且可以訪問 CDN 的數據，那就意味着我們可以控制 CDN 請求返回的內容或者HTTP 狀態，好像基本能夠解決我上面說的兩個問題，所以按照當前的技術能力和我們的需求我們針對請求鏈路進行了改造：

具體的降級和緩存清除的邏輯沒有畫出來，因爲那是解決安全生產的問題，我主要想強調方案調整帶來的性能提升。

所以從上圖可以看出，一個正常的請求首先會請求到 CDN，CDN 如果發現緩存中沒有的話會回源到 SSR 服務器，這樣首屏其實只需要一個網絡請求，有效的提升的首屏性能和降低了服務器壓力。細心的你會發現頁面首屏後還進行了一次請求動態數據的動作，因爲還有一個對實時性要求比較高的數據需要展示給用戶，但是並不影響用戶瀏覽，另外雖然內容不怎麼會更新但也會存在更新的情況，所以我們會在瀏覽器端做一次緩存的時間和內容最新更新時間的對比，如果發現不一致，會主動做緩存更新，這樣，既保證了性能，又避免了緩存過期

收益

通過做如上的方案我們在性能，業務指標提升，服務器壓力上都有很大的收穫

性能提升明顯，低端機首屏 1S 內

業務指標提升明顯

服務器壓力降低 80%

邊緣計算 ER

關於邊緣計算，大家可以參考： https://developer.aliyun.com/article/757950

本篇文章貼出幾張核心的圖供大家參考：

簡單總結就是我們可以在 CDN 返回結果之前進行一些邏輯計算，並且這部分代碼兼容 ES6 的規範，並且可以通過 HTTP 和外界服務進行溝通，達到有效的控制的 CDN 返回的表現的目的。

▐ 優勢-共享

在此我想重點介紹下邊緣計算的共享優勢，對於邊緣計算來說，它不僅可以處理一些邏輯計算，還可以將計算的結果進行存儲，存儲能力是 Swift 的 Open API ，實現數據的 KV 存儲，這就意味着，這個存儲空間可以非常大。

說道這裏大家可能會感覺比較抽象，可以看下面這張圖，上面是指我們正常的網絡請求，用戶手機直連數據服務器和頁面 CDN，這就意味每個人都要經歷加載頁面，加載數據，渲染頁面等邏輯。下面是指 CDN ER 做了一層代理，這就意味着用戶手機鏈接 CDN，CDN 負責和數據服務器和頁面 CDN 進行溝通。那樣這樣有什麼好處呢，這就意味着我們可以將像內容詳情這種數據或者渲染的結果直接存儲在 CDN 上，並且不用擔心存儲內容太多影響性能，這就就像一羣人公用一部手機，你看完傳遞給下一個人刷新看相同的內容。

▐ 優勢-計算能力

既然能在 CDN 的 ER 節點上寫 ES6 的代碼，並且可以請求數據，這就意味着我們可以在ER上執行很多邏輯，在這裏我整理一些常用的：

那基於這些能力我們還能支持哪些合適的場景落地呢，所以我們針對淘系的場景進行了調研。

場景調研

整體調研有一個統一的思路，就是要找適合靜態化的高流量場景，就是說頁面是否有可被緩存的數據或者渲染結果，爲此我們整理了一個簡單的表格：

接下來我做一些簡單的說明：

末端類型的頁面一般是有內容主體，並且這些主體數據不是千人千面的，例如上圖提到的，內容詳情、商品詳情、個人主頁、評論列表、評論詳情
搭建類業務，配置信息目前需要異步加載，模塊還要異步加載，這些配置化的東西是否可以直接和頁面一起輸出
榜單類型的頁面，同樣的一個榜單，每個人看到的都一樣，但是榜單要更新，但是這個更新並非真正的實時，一般爲了承載更大的流量，數據都是準實時，例如分鐘級更新，小時級更新，甚至一天更新一次，那在有效期內其實可以將榜單數據或者榜單的渲染結果緩存起來的

總結一下標準的頁面請求過程如下：

這裏說一下，其實在數據側有很多靜態化策略已經被用的遊刃有餘，例如藉助於 CDN、Tair、OSS，如果我們能夠讓靜態化的過程變得更加簡單和通用，例如將數據或者頁面渲染結果直接存儲在 CDN，下次請求就可以直接複用渲染結果，有沒有可能變成如下模式：

其實就是兩個原則：

減少 HTTP 請求次數，儘可能一次請求出首屏；
複用渲染結果：將渲染過程放在 ER 上並緩存下來，直接複用渲染結果，或者針對我們常用的骨架圖方案，是否能夠換成靜態數據的渲染結果；

場景標準化

最終結合 ER 的能力和我們的業務場景，我們抽象爲以下四種：

SSR 靜態化：指快速將 SSR 的結果緩存在 CDN 上
ESR(Edge Side Render)：顧名思義，將 renderToHTMLString 的過程放在 ER 節點上，並且緩存渲染結果
數據預請求：就是指將本來需要渲染後再請求數據的邏輯前置在 ER 上，將請求的結果合併返回給瀏覽器
Redirect：重定向，是指在 ER 上根據邏輯實現重定向的能力，相對於以往我們前端通過制定 location.href 的方式要快很多了，這個可以滿足邏輯分流需求，例如 AB
Include：片段注入，可以注入任何文字內容到任意文件類型中，一種更加通用的方案

經過我們的測試和實踐，針對前三種產出了一些性能報告也可以分享給大家，雖然不全面，但是能說明問題，由於測試的頁面場景不一樣，所以相互（數據預加載、 ESR、SSR 靜態化）沒有必要作對比，以下指標是相對沒有使用 TESI 的能力進行的對比。

標準化接入

雖然 ER 有這麼多優勢，但是接入成本還是比較大的，例如要注意 ER 容器本身的各種限制、調試成本、雲資源申請成本等，所以我們需要提供一種標準的接入方式，初步瞭解到 W3C 有一個 ESI 的標準，維基百科介紹如下：

Edge Side Includes or ESI is a small markup language for edge level dynamic web content assembly. The purpose of ESI is to tackle the problem of web infrastructure scaling. It is an application of edge computing.

簡單翻譯一下：ESI 是一種邊緣級 web 動態化的小型標記語言。ESI 的目的是解決 web 基礎設施的擴展問題。它是邊緣計算的一種應用方案

原理如圖：