本文同享来自淘系内容前端团队-蒂夫

前情

在开端正题之前，我先讲一个内容概略的业务场景和其面临的功用问题

业务特色

图文内容概略业务本身有三个比较大的特色：

• 内容量大，几十亿的内容量，并且每天还在张狂添加；
• 流量大，为了支撑这么大的业务，需求许多服务器本钱；
• 内容[ @ Y .数据X 6 : V ~ N b u极具静态化，页面参看如下，除了蓝色标识的数据，其他数据很少会改动；

那我们看这么一个页面的加载和d r : N @ : c烘托进程大概是什么样的？

总结问题

从上面的流程能够看出几个问题：

• 首屏烘托依托多次央求，导致首屏烘托功用差，尤其是低端机
• 服务端压力大，每次央求都需求央求到服务端，对服务器也会带来非常大的压力
• 内容重y v r u复烘托，相同一篇内容每个人看到都相同，但是烘托效果又无法同享

大胆考P D 3 Y # * 9 [ ;虑

这时候我们要结合业务本身的特性进行3 & 0 J H Z + 3 I一些大胆H z ~ ~ K 6的考虑：

研制时预烘托l F [ r d

首s ; ? p要想到的是在研制进程中就对内容进行预烘托并存储起来，但是这个方案很快被 pass 了，有两个首要原因：

• 内容量太大：内容数量特别大，并且一} ~ R d c P 7 G篇内容在h l K g J 8 R y不同的场` V [景（上百# H E j）还会议 a 3 u B [ P y }现出不同的风格，全部静态化存储 CDN 资源糟蹋严重
• 更新本钱大：内容会被达人修改，或许一些打擦边球的内容需求从速下线

按需烘托效果静态化

已然数据绝大部分是静态化的，为什么不能把用户访问时静态数据和代码烘托后的效果进行静态化，这样不是省去了 rendeb 4 QrToHTML 的进程了吗？，如下图所示

那讲到8 u a , U这儿，我们首要想到的是经过 SSR renderToHTMR ~ q x ILString，然后把烘托后的效果进行缓存，这样访问到相同内容的央求能够直接将缓存效果回来，那这样有什X $ V c – S么长处呢：| # – | a

• 削减重复烘托，进步首屏功用
• 下降接口服务的压力
• 基于访问存储，避免资源糟蹋

但是一同也带来了其他的问题：

• SSR 应用U I x E U 8 T x服务器间隔用户远带来的白屏时刻延伸t L r i ) 8 d 1 B
• SSR 本身的压力也会进步，由于这样意味着V ; Q = H K F _每一个用户央求都要经过 SSR（尽g ) P j W ~ # q ,管能够走缓存）
• 缓存数据存储的问题，存9 ] _ C ^ = 0 K哪里，内存肯定不满足需求，由于刚开端就讲n ( * 5 L u e Z到了内容量特别大，这时i M 7候要借助于其他的一些快速存储的云服务，显得特别杂乱

这时候我们就在想，假设能够将烘托的效果或许烘托的进程放在 CDN 上就好了，由于 CDN 节点比较多，并且在世界范围布置广泛，所以我们尝试着将 SSR 烘托的效果存储在 CDN 上，但是随之带来其他一些问E J I K A z D (题：

• SSR 服务器出错了怎样办，现在 CDN 是一种配备收效系统，如下图所示，我们上文提到了图文概略的) l 4 * w ,流量特别大，这也就意味着各种异常情况都要考虑，像 SSR 服务器宕机带来的危险我们也必须有降级方案，确保不影响用户

• 关于两种特别场景需求及时更新缓存：擦边球内容要能够及时下线，页面代码更新要能够批量更新缓存，现在经过 CDN 的配备项是处理不了这些问题的

这时我们正好了解到了 CDN 正在推广一种边沿核算的才干（EdgeRoutine，下面会做简略的介绍），简略点了解] @ M | o N就是能够在 CDN 央求回来效果之前加上你的自定义脚本，并且能够访问 CDQ Z R ] O o [ 5 3N 的数据，那就意味着我们能够操控 CDN 央求回来的内容或许HTTP 情况，好像底子能够处理我上4 , g I 面说的两个问题，所以按照当前的技能才W & ~ K ) e k 2 *能和( e c 0 = B W y 7我们的需求我们针对央求链路进行了改造：

详细的降级和缓存根除的逻辑没有画出来，由于那是处理安全出产的问题，我首要想着重方案调整带来的功用进步。

所以8 & W d 2 D =从上图能够看出，一个正常的央求首要会央求# C , w到 CDN，CDN 假设发现缓存中没有的话会回源到 SSR 服务器，这样5 F ; R c $ *首屏其实只需求一个网络央求，有用的进步的首屏功用和下降了服务器压力。细心的你会发现页面首屏后4 c 4 # S I ]还进行了一次央求动态数据的动作，由于还有一个对实时性要求比较Y n f P [高J 0 J . d N @ W的数据需求展示给用户，但是并不影响用户浏览，其他尽管内容不怎样会更新但也会存在更新的情况，所W 4 i W W p 3 ) ]以我们会在浏览器端做一次缓存的时刻和内容最新更新时刻的对比，假设发现不共同，会自动做缓存更新，这样，既确保了功用，又避免了缓存过期

收益

经过做如上的方案我们在功用，业务方针进步– [ f R，服务器压力上都有很大的收成

功用进步明显，低端机首屏 1S 内

业务方针进步明显

服务器压力Q * A : j Z B下降 80%

边沿核算 E# S R J YR

关于边沿核算，我们能够参看：developer.aliyun.com/ak e O #rticle/757…

本篇文章贴出几张核心的图供我们参看：

简略总结就是我们能够在 CDN 回来效果之前进行一些逻辑核算，并且这部分代码兼容 ES6 的标准，并且能够经过 HTTP 和外界服务进行沟通，到达有用的操控的 CDQ j Y { ) ( l MN 回来的体现的意图

优势-同享

在此我想关键介绍下边沿核算的同享优势，关于边沿核算来说，它不只能够处理一些逻辑核算，还能够将核算的效果进行存储，存储才干是 Swift 的 Open API ，完q L t – W x ! _ w成数据的 KV 存储，这就意味着，这个存储X f j 9 ~ m K空间能够非常大。说道这儿我们可能会感觉比较笼统，能够看下面这张图，上面是指我们正常的网络央求，用户手机直连数据服务器和页1 D P (面K w H I @ G B CDN，这就意味每个人都要履历加载页面，加载数据，烘托页面等逻辑。下面是指 CDN ER 做了一层代理，这就意味着用户手机链接H & : E ^ } { CDN，CDN 担任和数据服务器和页面 CDN 进行沟通。那样这样有什么长处呢，这就意味着2 f = / @ * R我们能够z f G Y e将像内容概略这种数据或许烘托的效果直接存储在 CDN 上，并且不必忧虑存储内容太多影响功用，这就就像一群人公! ] W 4 – : & Z用一部手机，你看完传递给下一个人B q 5改写看相同的内容

优势-核算才干

已然能在 CDN 的 ER 节点上写 ES6 的代码，并且能够央求数据，这就意味着 ; E我们能够在ER上实行许多逻辑，在这儿我拾掇一些常用的：

那基于这些才干我们还能支撑哪些适宜的场景落地呢，所以我们针对淘系的场景进行了调研

场景调研

整体调研有一个共同的思路，就是要找适J ] * l h宜静态化的高流量场景，就是说$ M ~ l V k页面是否有可被缓存的数据或许烘托效果，为此我们拾掇了一个简略的表T – D ` o ` ~格：

接下来我x = H y E做一些简略的说明U # z @：

• 结尾类S e e d U型的页面一般是有内容主体，并且这些主体数据不是千人千面的，例如上图提到的，内容概略、商品概略、个人主页、谈论列表、谈论概略
• 建立类业务，配备信息现在需求异步加载，模块还要异步加载，这些配备化的东西是否能够直接和页面一同输出
• 榜单类型的页面，相同的一个榜单，每个人看8 # U i *到的都相同，但是榜单要更新，但是这个更新并非实在的实时，一般为了承载更大的流量，数据k U u都是准实时，例如分钟级更新，小时) c : 1 D级更c I B m p $新，甚至一天更新一次，那在有用期内其实能够将榜单数据或许榜单的烘托效果缓存起来的

总结3 # w $ | . * k h一下标准的页面央求进程如下：

这儿说一下，其实在数据侧有许多静态化战略现已被| G 9 R z用的笔底生花，例如借助于 CDN、Tair、OSS~ d ` G S，假设我们能够让静态化的进程变得更加简略和通用，例如将p R X数据或许页面烘托效果直接存储在 CDN，下次恳2 v ?求就能够直_ C 5 z c W ( j接复用烘托效果，有没有可能变成如下方式：

其实就是两个准则：

• 削减 HTTP 央求次数，尽可能一次央求出首屏7 ` y；
• 复用R @ y R = T D烘R q S 3托效果：将烘托进程放在 ER 上并缓( } 1 ] f 4存下来，直接复用烘托效果，或许针对我们常b Z . h用的骨架图方案，是否能够换成静态数据的烘托效果；

场 – l f E / O景标准化

最终结合 ER 的才干和我们的业务场景，我们笼统为以下四种：

• SSR 静态化：指快速将 SSR 的效果缓存在 CDN 上
• ESR(Edge Side Render)：顾名思义，将 renderToHTMLString 的进程放在 ER 节点上，并且缓存烘j + ? _ Z托效果
• 数据预央求：就是指7 Y = T !将原本需求烘托后再央求数据的逻辑前置在 ER 上，将央求的效果兼并回来给浏览器
• Redirect：重定向，是指在 ER 上根据逻辑结束重定向的才干，相关于以往我们前端经过拟定 location.href 的办法要快许多了，这个能够满足逻辑分U s D n ^ p流需求，例如 AB
• Include：片段注入，能够注入任何文字内容就任意文件类型中，一种更加通用的方案

经过我们的测验和实践，针对前三种产7 e r出了一些功用陈述也能够同享给我们，尽e 5 w C – l 6管不全面，但是能说明问题，由于测验的页面场景不相同，所以互相（数据预加载、 ESR、SSR 静态化）没有必要作对比，以下方针是相对没有运用 TESI 的才干进行的对比

标准化接入

尽管i , U z ER 有这么多优势，但是接入本钱仍是比较大的，例如要注意 ER 容器本身的各种限制、调试本钱、云资源请求本钱O g Z 9 w j + .等，所以我们需求供应一种标准的接入办法，开始了解到 W3C 有一个 ESI 的标准，维基百科介绍如下：

简略翻译一下：ESI 是一种边沿级 web 动态化的小型符号语言。ESI 的意图是处理 web 基础设u R / L E u施的扩展问题。它是边沿核算的一种应用方案

原理如图f 4 Y D 4 6：

其实就是说，, = g B # o能够经过标签Z ? l / X注入的办法，结束动态8 W u内容混合混合输出，比较契合我们的诉求，并且其在语法上3 9 P @ {也比较丰富

但问题是 ESI 是一种 XML 的标准，阿里有许多页面资源类型并不是 HTML，例如 weex、小程序等等，它们加载的页面并不是 HTML，并且我们要满足标准化场景的接入，所R w ? k以我们需求t N @ d +在 ESI 的基础上进行改造-TESI（Taobao E P | l ~ &dge Side Includes），适宜的才是最好的

底子的代码方式怎样，我们以数据预加载为例，如下 H5 中呈现 TESI 标U y X o G签（鼠标选中部分w k Q L ? g H L）

TESI 标签描绘了一个 http 接口的信s t | j ^ d息，并且配备了其缓存时长 s-maD : @ 8 1 yxage，ER 会解析这个标签，并且在 ER 上建议央求，并将央求的数据按照l ] ~ 7 = – f s-maxage 配备的值进行缓存，这就意味着下一次央求到相同的节点，就会直接回来缓存效果

烘4 1 } | 5 L I & K托效果如下：

我们看其实像数据预加载这种情况，在 HTML 中会烘托成一个 scriptj e h l 标签，其中存储的是一个全局变量便利运行时获取。

其实 TESI 标签不只能够用于 HTML 中，JS 中能够呈现 TESI 标签D b g [ E E，如下：

烘托后

其根C / r k Q ~ L r r本烘托原理如下，比较简略，这儿不做赘余：

还有其他几种类型的标签如下：

安稳降级

整个 EA d ) ` ? WR 实行的进程会遇0 V f到各式各样的问V q X _题，甚至 ER 都有挂掉的危险，所以需求有安稳降级的预案保– u V )证不影响用户，所以 & m G 2 (我们会将 CDN 源站指向页面 CDN 的源站，这样，及时 ER 解析呈现问题，能够把解析前的页面直接回来给浏览器

缓存处理

存储

ER 供应了两种缓存：内存缓存（以下简称 Cache）和 Swift KV 缓存（以下简称 KV），这两种方式在存取速度、体积大小、QPS 上都有差别，总结底子如下：

这儿指的存储副作用是指，存储大小关于 ER 功用的影响，存储在缓存中，假设存储体积接近内存大小，首要会影响 ER 实行功用，严重会导致 ER 容器重启

归纳以上两种对比效果来看各有千秋，但O U @ M : N j适宜的场景用适宜的方式才是最好，为此我们设计了二级缓存方式，一级缓存存入内存，二级缓存u 7 w B ]存入 KV，首要结束如下三个关键逻辑：

• 动态核算热度内容推入一级缓存
• 采用 LW y @ + ARU（最近最久未运用算法）的方式结束一级缓存和二级缓存的数据推出，充分利用缓存空间
• 每一个标签y 8 E J e z * p W设定指定的缓存空间，避免缓存分配不均，导致互相影响

缓存失效

缓存的内容需求具有快速根除的才干，由于数据会更新、页面 bundle 会更新，特别是遇到急迫情况，例如线上问题急迫修正，需求能够结束缓存及时根除，所以需求必定的战略来满足需求，总7 ; @ A b k ! U体根除的逻辑会依托央求，根据标签的身K { B Q D w 5 $份信息进行根除

接入进程

为了满足系统安稳性和安全出产} 0 L K s f的要求，TE9 A p 5 GSI 标签的出产进程是需求被管控起来的，所以我们要供应一个 TESIe F # M v ) M Z I 的运维系统首要满足以下几个需求：

运维系统运用进程如下：

运维系统首要为了生成一u 5 r个可用的 TESI 标签，实在发布收效我们会借助于 DEF 发布系统，这样既沿用了标准，安全出产相关才干我们也不必重复建设了，底子流T b } @ G { y N y程如下：

附录

名词介绍：y k k 0 0 K 1 c

• ER：EdgeRoutin a – = *e
• ESR: Edge Side R? w * , q ` ~ p Lender
• SSR:D ? | Server Side RE k render
• ESI: Edge` j B f Side IO N ] R * A s Uncludes
• TESI: Taobao Edge Side Includes
• DEF: 阿里& – 3 l J ^前端发布系统
• Swift：阿里云 CDN 文件存储

几种常用服务类型简介：

其底子的配备信息和实行进程如下，我们能够参看下：

最终

仍是亘古不变的论题，假设你对边沿核算感兴趣，欢迎参与我们共同建设，假设你对我们的业务感兴趣，也欢迎你的参与，c $ o 8 C l B业务了解：zhuanlan.zhihu.com/p( ` 2/128956855

简历投递：yabing.zyb@alibaba-inc.com

主题备注：前端-公司-名字