前情

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

業務特點

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

• 內容量大，幾十億的內容量，并且每天還在瘋狂增長；

• 流量大，為了支撐這么大的業務，需要很多服務器成本；

• 內容數據極具靜態化，頁面參考如下，除了藍色標識的數據，其他數據很少會改動；

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

總結問題

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

• 首屏渲染依賴多次請求，導致首屏渲染性能差，尤其是低端機

• 服務端壓力大，每次請求都需要請求到服務端，對服務器也會帶來非常大的壓力

• 內容重復渲染，同樣一篇內容每個人看到都一樣，但是渲染結果又無法共享

大膽思考

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

研發時預渲染

首先想到的是在研發過程中就對內容進行預渲染并存儲起來，但是這個方案很快被 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

關于邊緣計算，大家可以參考：developer.aliyun.com/article/757…

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

簡單總結就是我們可以在 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 的標準，維基百科介紹如下：

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

原理如圖：

其實就是說，可以通過標簽注入的方式，實現動靜內容混合混合輸出，比較符合我們的訴求，并且其在語法上也比較豐富

但問題是 ESI 是一種 XML 的標準，阿里有很多頁面資源類型并不是 HTML，例如 weex、小程序等等，它們加載的頁面并不是 HTML，并且我們要滿足標準化場景的接入，所以我們需要在 ESI 的基礎上進行改造-TESI（Taobao Edge Side Includes），合適的才是最好的

基本的代碼形式如何，我們以數據預加載為例，如下 H5 中出現 TESI 標簽（鼠標選中部分）

TESI 標簽描述了一個 http 接口的信息，并且配置了其緩存時長 s-maxage，ER 會解析這個標簽，并且在 ER 上發起請求，并將請求的數據按照 s-maxage 配置的值進行緩存，這就意味著下一次請求到相同的節點，就會直接返回緩存結果

渲染結果如下：

我們看其實像數據預加載這種情況，在 HTML 中會渲染成一個 script 標簽，其中存儲的是一個全局變量方便運行時獲取。

其實 TESI 標簽不僅可以用于 HTML 中，JS 中可以出現 TESI 標簽，如下：

渲染后

其基本渲染原理如下，比較簡單，這里不做贅余：

還有其他幾種類型的標簽如下：

穩定降級

整個 ER 執行的過程會遇到各種各樣的問題，甚至 ER 都有掛掉的風險，所以需要有穩定降級的預案保證不影響用戶，所以我們會將 CDN 源站指向頁面 CDN 的源站，這樣，及時 ER 解析出現問題，可以把解析前的頁面直接返回給瀏覽器

緩存管理

存儲

ER 提供了兩種緩存：內存緩存（以下簡稱 Cache）和 Swift KV 緩存（以下簡稱 KV），這兩種模式在存取速度、體積大小、QPS 上都有差別，總結基本如下：

這里指的存儲副作用是指，存儲大小對于 ER 性能的影響，存儲在緩存中，如果存儲體積接近內存大小，首先會影響 ER 執行性能，嚴重會導致 ER 容器重啟

綜合以上兩種對比結果來看各有千秋，但合適的場景用合適的模式才是最好，為此我們設計了二級緩存模式，一級緩存存入內存，二級緩存存入 KV，主要完成如下三個重點邏輯：

• 動態計算熱度內容推入一級緩存

• 采用 LRU（最近最久未使用算法）的模式實現一級緩存和二級緩存的數據推出，充分利用緩存空間

• 每一個標簽設定指定的緩存空間，避免緩存分配不均，導致相互影響

緩存失效

緩存的內容需要具備快速清除的能力，因為數據會更新、頁面 bundle 會更新，特別是遇到緊急情況，例如線上問題緊急修復，需要能夠實現緩存及時清除，所以需要一定的策略來滿足需求，總體清除的邏輯會依賴請求，根據標簽的身份信息進行清除

接入過程

為了滿足系統穩定性和安全生產的要求，TESI 標簽的生產過程是需要被管控起來的，所以我們要提供一個 TESI 的運維系統主要滿足以下幾個需求：

運維系統使用過程如下：

運維系統主要為了生成一個可用的 TESI 標簽，真正發布生效我們會借助于 DEF 發布系統，這樣既沿用了標準，安全生產相關能力我們也不用重復建設了，基本流程如下：

附錄

名詞介紹：

• ER：EdgeRoutine

• ESR: Edge Side Render

• SSR: Server Side Render

• ESI: Edge Side Includes

• TESI: Taobao Edge Side Includes

• DEF: 阿里前端發布系統

• Swift：阿里云 CDN 文件存儲

幾種常用服務類型簡介：

其基本的配置信息和執行過程如下，大家可以參考下：