婷婷丁香五月天影院亚洲综合桃花 ,经典国产三级在线,美女操逼逼,在线免费观看亚洲网站,久久人妻无码,做爱免费网站,亚洲秘无码一区二区三区密桃,日本成人少妇

NO.1

前情

在開始正題之前，我先講一個(gè)內(nèi)容詳情的業(yè)務(wù)場(chǎng)景和其面臨的性能問題

業(yè)務(wù)特點(diǎn)

圖文內(nèi)容詳情業(yè)務(wù)本身有三個(gè)比較大的特點(diǎn)：

內(nèi)容量大，幾十億的內(nèi)容量，并且每天還在瘋狂增長(zhǎng)；
流量大，為了支撐這么大的業(yè)務(wù)，需要很多服務(wù)器成本；
內(nèi)容數(shù)據(jù)極具靜態(tài)化，頁面參考如下，除了藍(lán)色標(biāo)識(shí)的數(shù)據(jù)，其他數(shù)據(jù)很少會(huì)改動(dòng)；

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

總結(jié)問題

從上面的流程可以看出幾個(gè)問題：

首屏渲染依賴多次請(qǐng)求，導(dǎo)致首屏渲染性能差，尤其是低端機(jī)
服務(wù)端壓力大，每次請(qǐng)求都需要請(qǐng)求到服務(wù)端，對(duì)服務(wù)器也會(huì)帶來非常大的壓力
內(nèi)容重復(fù)渲染，同樣一篇內(nèi)容每個(gè)人看到都一樣，但是渲染結(jié)果又無法共享

大膽思考

這時(shí)候我們要結(jié)合業(yè)務(wù)本身的特性進(jìn)行一些大膽的思考：

研發(fā)時(shí)預(yù)渲染

首先想到的是在研發(fā)過程中就對(duì)內(nèi)容進(jìn)行預(yù)渲染并存儲(chǔ)起來，但是這個(gè)方案很快被 pass 了，有兩個(gè)主要原因：

內(nèi)容量太大：內(nèi)容數(shù)量特別大，并且一篇內(nèi)容在不同的場(chǎng)景（上百）還會(huì)展示出不同的風(fēng)格，全部靜態(tài)化存儲(chǔ) CDN 資源浪費(fèi)嚴(yán)重
更新成本大：內(nèi)容會(huì)被達(dá)人修改，或者一些打擦邊球的內(nèi)容需要盡快下線

按需渲染結(jié)果靜態(tài)化

既然數(shù)據(jù)絕大部分是靜態(tài)化的，為什么不能把用戶訪問時(shí)靜態(tài)數(shù)據(jù)和代碼渲染后的結(jié)果進(jìn)行靜態(tài)化，這樣不是省去了 renderToHTML 的過程了嗎？，如下圖所示

那講到這里，我們首先想到的是通過 SSR renderToHTMLString，然后把渲染后的結(jié)果進(jìn)行緩存，這樣訪問到相同內(nèi)容的請(qǐng)求可以直接將緩存結(jié)果返回，那這樣有什么好處呢：

減少重復(fù)渲染，提升首屏性能
降低接口服務(wù)的壓力
基于訪問存儲(chǔ)，避免資源浪費(fèi)

但是同時(shí)也帶來了其他的問題：

SSR 應(yīng)用服務(wù)器距離用戶遠(yuǎn)帶來的白屏?xí)r間延長(zhǎng)
SSR 本身的壓力也會(huì)提升，因?yàn)檫@樣意味著每一個(gè)用戶請(qǐng)求都要經(jīng)過 SSR（雖然可以走緩存）
緩存數(shù)據(jù)存儲(chǔ)的問題，存哪里，內(nèi)存肯定不滿足需求，因?yàn)閯傞_始就講到了內(nèi)容量特別大，這時(shí)候要借助于其他的一些快速存儲(chǔ)的云服務(wù)，顯得特別復(fù)雜

這時(shí)候我們就在想，如果能夠?qū)秩镜慕Y(jié)果或者渲染的過程放在 CDN 上就好了，因?yàn)?CDN 節(jié)點(diǎn)比較多，并且在世界范圍部署廣泛，所以我們嘗試著將 SSR 渲染的結(jié)果存儲(chǔ)在 CDN 上，但是隨之帶來另外一些問題：

SSR 服務(wù)器出錯(cuò)了怎么辦，現(xiàn)在 CDN 是一種配置生效系統(tǒng)，如下圖所示，我們上文說到了圖文詳情的流量特別大，這也就意味著各種異常情況都要考慮，像 SSR 服務(wù)器宕機(jī)帶來的風(fēng)險(xiǎn)我們也必須有降級(jí)方案，保障不影響用戶

對(duì)于兩種特殊場(chǎng)景需要及時(shí)更新緩存：擦邊球內(nèi)容要能夠及時(shí)下線，頁面代碼更新要能夠批量更新緩存，目前通過 CDN 的配置項(xiàng)是解決不了這些問題的

這時(shí)我們正好了解到了 CDN 正在推廣一種邊緣計(jì)算的能力（EdgeRoutine，下面會(huì)做簡(jiǎn)單的介紹），簡(jiǎn)單點(diǎn)理解就是可以在 CDN 請(qǐng)求返回結(jié)果之前加上你的自定義腳本，并且可以訪問 CDN 的數(shù)據(jù)，那就意味著我們可以控制 CDN 請(qǐng)求返回的內(nèi)容或者HTTP 狀態(tài)，好像基本能夠解決我上面說的兩個(gè)問題，所以按照當(dāng)前的技術(shù)能力和我們的需求我們針對(duì)請(qǐng)求鏈路進(jìn)行了改造：

具體的降級(jí)和緩存清除的邏輯沒有畫出來，因?yàn)槟鞘墙鉀Q安全生產(chǎn)的問題，我主要想強(qiáng)調(diào)方案調(diào)整帶來的性能提升。所以從上圖可以看出，一個(gè)正常的請(qǐng)求首先會(huì)請(qǐng)求到 CDN，CDN 如果發(fā)現(xiàn)緩存中沒有的話會(huì)回源到 SSR 服務(wù)器，這樣首屏其實(shí)只需要一個(gè)網(wǎng)絡(luò)請(qǐng)求，有效的提升的首屏性能和降低了服務(wù)器壓力。細(xì)心的你會(huì)發(fā)現(xiàn)頁面首屏后還進(jìn)行了一次請(qǐng)求動(dòng)態(tài)數(shù)據(jù)的動(dòng)作，因?yàn)檫€有一個(gè)對(duì)實(shí)時(shí)性要求比較高的數(shù)據(jù)需要展示給用戶，但是并不影響用戶瀏覽，另外雖然內(nèi)容不怎么會(huì)更新但也會(huì)存在更新的情況，所以我們會(huì)在瀏覽器端做一次緩存的時(shí)間和內(nèi)容最新更新時(shí)間的對(duì)比，如果發(fā)現(xiàn)不一致，會(huì)主動(dòng)做緩存更新，這樣，既保證了性能，又避免了緩存過期

收益

通過做如上的方案我們?cè)谛阅?，業(yè)務(wù)指標(biāo)提升，服務(wù)器壓力上都有很大的收獲

性能提升明顯，低端機(jī)首屏 1S 內(nèi)

業(yè)務(wù)指標(biāo)提升明顯

服務(wù)器壓力降低 80%

NO.2

邊緣計(jì)算 ER

關(guān)于邊緣計(jì)算，大家可以參考：https://developer.aliyun.com/article/757950
本篇文章貼出幾張核心的圖供大家參考：

簡(jiǎn)單總結(jié)就是我們可以在 CDN 返回結(jié)果之前進(jìn)行一些邏輯計(jì)算，并且這部分代碼兼容 ES6 的規(guī)范，并且可以通過 HTTP 和外界服務(wù)進(jìn)行溝通，達(dá)到有效的控制的 CDN 返回的表現(xiàn)的目的

優(yōu)勢(shì)-共享

在此我想重點(diǎn)介紹下邊緣計(jì)算的共享優(yōu)勢(shì)，對(duì)于邊緣計(jì)算來說，它不僅可以處理一些邏輯計(jì)算，還可以將計(jì)算的結(jié)果進(jìn)行存儲(chǔ)，存儲(chǔ)能力是 Swift 的 Open API ，實(shí)現(xiàn)數(shù)據(jù)的 KV 存儲(chǔ)，這就意味著，這個(gè)存儲(chǔ)空間可以非常大。說道這里大家可能會(huì)感覺比較抽象，可以看下面這張圖，上面是指我們正常的網(wǎng)絡(luò)請(qǐng)求，用戶手機(jī)直連數(shù)據(jù)服務(wù)器和頁面 CDN，這就意味每個(gè)人都要經(jīng)歷加載頁面，加載數(shù)據(jù)，渲染頁面等邏輯。下面是指 CDN ER 做了一層代理，這就意味著用戶手機(jī)鏈接 CDN，CDN 負(fù)責(zé)和數(shù)據(jù)服務(wù)器和頁面 CDN 進(jìn)行溝通。那樣這樣有什么好處呢，這就意味著我們可以將像內(nèi)容詳情這種數(shù)據(jù)或者渲染的結(jié)果直接存儲(chǔ)在 CDN 上，并且不用擔(dān)心存儲(chǔ)內(nèi)容太多影響性能，這就就像一群人公用一部手機(jī)，你看完傳遞給下一個(gè)人刷新看相同的內(nèi)容

優(yōu)勢(shì)-計(jì)算能力

既然能在 CDN 的 ER 節(jié)點(diǎn)上寫 ES6 的代碼，并且可以請(qǐng)求數(shù)據(jù)，這就意味著我們可以在ER上執(zhí)行很多邏輯，在這里我整理一些常用的：

那基于這些能力我們還能支持哪些合適的場(chǎng)景落地呢，所以我們針對(duì)淘系的場(chǎng)景進(jìn)行了調(diào)研

NO.3

場(chǎng)景調(diào)研

整體調(diào)研有一個(gè)統(tǒng)一的思路，就是要找適合靜態(tài)化的高流量場(chǎng)景，就是說頁面是否有可被緩存的數(shù)據(jù)或者渲染結(jié)果，為此我們整理了一個(gè)簡(jiǎn)單的表格：

接下來我做一些簡(jiǎn)單的說明：

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

總結(jié)一下標(biāo)準(zhǔn)的頁面請(qǐng)求過程如下：

這里說一下，其實(shí)在數(shù)據(jù)側(cè)有很多靜態(tài)化策略已經(jīng)被用的游刃有余，例如借助于 CDN、Tair、OSS，如果我們能夠讓靜態(tài)化的過程變得更加簡(jiǎn)單和通用，例如將數(shù)據(jù)或者頁面渲染結(jié)果直接存儲(chǔ)在 CDN，下次請(qǐng)求就可以直接復(fù)用渲染結(jié)果，有沒有可能變成如下模式：

其實(shí)就是兩個(gè)原則：

減少 HTTP 請(qǐng)求次數(shù)，盡可能一次請(qǐng)求出首屏；
復(fù)用渲染結(jié)果：將渲染過程放在 ER 上并緩存下來，直接復(fù)用渲染結(jié)果，或者針對(duì)我們常用的骨架圖方案，是否能夠換成靜態(tài)數(shù)據(jù)的渲染結(jié)果；

NO.4

場(chǎng)景標(biāo)準(zhǔn)化

最終結(jié)合 ER 的能力和我們的業(yè)務(wù)場(chǎng)景，我們抽象為以下四種：

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

經(jīng)過我們的測(cè)試和實(shí)踐，針對(duì)前三種產(chǎn)出了一些性能報(bào)告也可以分享給大家，雖然不全面，但是能說明問題，由于測(cè)試的頁面場(chǎng)景不一樣，所以相互（數(shù)據(jù)預(yù)加載、 ESR、SSR 靜態(tài)化）沒有必要作對(duì)比，以下指標(biāo)是相對(duì)沒有使用 TESI 的能力進(jìn)行的對(duì)比

NO.5

標(biāo)準(zhǔn)化接入

雖然 ER 有這么多優(yōu)勢(shì)，但是接入成本還是比較大的，例如要注意 ER 容器本身的各種限制、調(diào)試成本、云資源申請(qǐng)成本等，所以我們需要提供一種標(biāo)準(zhǔn)的接入方式，初步了解到 W3C 有一個(gè) ESI 的標(biāo)準(zhǔn)，維基百科介紹如下：
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.
簡(jiǎn)單翻譯一下：ESI 是一種邊緣級(jí) web 動(dòng)態(tài)化的小型標(biāo)記語言。ESI 的目的是解決 web 基礎(chǔ)設(shè)施的擴(kuò)展問題。它是邊緣計(jì)算的一種應(yīng)用方案原理如圖：

其實(shí)就是說，可以通過標(biāo)簽注入的方式，實(shí)現(xiàn)動(dòng)靜內(nèi)容混合混合輸出，比較符合我們的訴求，并且其在語法上也比較豐富

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

基本的代碼形式如何，我們以數(shù)據(jù)預(yù)加載為例，如下 H5 中出現(xiàn) TESI 標(biāo)簽（鼠標(biāo)選中部分）

TESI 標(biāo)簽描述了一個(gè) http 接口的信息，并且配置了其緩存時(shí)長(zhǎng) s-maxage，ER 會(huì)解析這個(gè)標(biāo)簽，并且在 ER 上發(fā)起請(qǐng)求，并將請(qǐng)求的數(shù)據(jù)按照 s-maxage 配置的值進(jìn)行緩存，這就意味著下一次請(qǐng)求到相同的節(jié)點(diǎn)，就會(huì)直接返回緩存結(jié)果
渲染結(jié)果如下：

我們看其實(shí)像數(shù)據(jù)預(yù)加載這種情況，在 HTML 中會(huì)渲染成一個(gè) script 標(biāo)簽，其中存儲(chǔ)的是一個(gè)全局變量方便運(yùn)行時(shí)獲取。其實(shí) TESI 標(biāo)簽不僅可以用于 HTML 中，JS 中可以出現(xiàn) TESI 標(biāo)簽，如下：

渲染后

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

還有其他幾種類型的標(biāo)簽如下：

標(biāo)簽名	描述
tesi:data	數(shù)據(jù)預(yù)加載
tesi:esr	邊緣渲染
tesi:ssr	SSR 靜態(tài)化
tesi:redirect	邏輯跳轉(zhuǎn)
tesi:include	區(qū)塊引入

NO.6

穩(wěn)定降級(jí)

整個(gè) ER 執(zhí)行的過程會(huì)遇到各種各樣的問題，甚至 ER 都有掛掉的風(fēng)險(xiǎn)，所以需要有穩(wěn)定降級(jí)的預(yù)案保證不影響用戶，所以我們會(huì)將 CDN 源站指向頁面 CDN 的源站，這樣，及時(shí) ER 解析出現(xiàn)問題，可以把解析前的頁面直接返回給瀏覽器

NO.7

緩存管理

存儲(chǔ)

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

指標(biāo)	VS	勝出
存儲(chǔ)空間	Cache?﹤?KV	KV，可達(dá) 幾十 GB
QPS	Cache ﹥ KV	Cache
存取速度	Cache ﹥ KV	Cache
存儲(chǔ)副作用	Cache ﹥ KV	KV

這里指的存儲(chǔ)副作用是指，存儲(chǔ)大小對(duì)于 ER 性能的影響，存儲(chǔ)在緩存中，如果存儲(chǔ)體積接近內(nèi)存大小，首先會(huì)影響 ER 執(zhí)行性能，嚴(yán)重會(huì)導(dǎo)致 ER 容器重啟綜合以上兩種對(duì)比結(jié)果來看各有千秋，但合適的場(chǎng)景用合適的模式才是最好，為此我們?cè)O(shè)計(jì)了二級(jí)緩存模式，一級(jí)緩存存入內(nèi)存，二級(jí)緩存存入 KV，主要完成如下三個(gè)重點(diǎn)邏輯：

動(dòng)態(tài)計(jì)算熱度內(nèi)容推入一級(jí)緩存
采用 LRU（最近最久未使用算法）的模式實(shí)現(xiàn)一級(jí)緩存和二級(jí)緩存的數(shù)據(jù)推出，充分利用緩存空間
每一個(gè)標(biāo)簽設(shè)定指定的緩存空間，避免緩存分配不均，導(dǎo)致相互影響

緩存失效

緩存的內(nèi)容需要具備快速清除的能力，因?yàn)閿?shù)據(jù)會(huì)更新、頁面 bundle 會(huì)更新，特別是遇到緊急情況，例如線上問題緊急修復(fù)，需要能夠?qū)崿F(xiàn)緩存及時(shí)清除，所以需要一定的策略來滿足需求，總體清除的邏輯會(huì)依賴請(qǐng)求，根據(jù)標(biāo)簽的身份信息進(jìn)行清除

NO.8

接入過程

為了滿足系統(tǒng)穩(wěn)定性和安全生產(chǎn)的要求，TESI 標(biāo)簽的生產(chǎn)過程是需要被管控起來的，所以我們要提供一個(gè) TESI 的運(yùn)維系統(tǒng)主要滿足以下幾個(gè)需求：

運(yùn)維系統(tǒng)使用過程如下：

運(yùn)維系統(tǒng)主要為了生成一個(gè)可用的 TESI 標(biāo)簽，真正發(fā)布生效我們會(huì)借助于 DEF 發(fā)布系統(tǒng)，這樣既沿用了標(biāo)準(zhǔn)，安全生產(chǎn)相關(guān)能力我們也不用重復(fù)建設(shè)了，基本流程如下：