>>发布会传送门：https://yqh.aliyun.com/live/detail/21749
点击查看详情：https://yqh.aliyun.com/live/cdn_0106
随着云原生技术的普及，阿里云可编程CDN能力逐渐增强，已经实现在靠近用户的边缘，支持将无状态的业务逻辑以函数或容器的方式在边缘完成算力卸载，以此提供最短时延的交互响应。同时，基于阿里云CDN平台强大的基础资源能力和高性能架构，可以轻松满足企业海量的弹性需求。
阿里云CDN具有全球2800+个节点的巨大节点网络，可以将源站静态文件（例如图片、视频）缓存起来，全球各地客户端就近请求CDN节点即可拿到文件，相比请求服务器源站肯定是大大缩短了网络链路降低了延时，同时，还降低了源站压力，源站不用接收请求，分散到各地的CDN节点处理了。而现在阿里云CDN除了缓存和分发，更是具备了就近分发计算的能力，这就是EdgeRoutine。在1月6日的阿里云CDN年度产品升级发布会中，阿里云高级产品经理陈章炜对EdgeRoutine进行了详细解读。
EdgeRoutine——让计算服务更加靠近你的用户
EdgeRoutine是一个运行在CDN边缘节点上的JavaScript代码运行环境，用户可以将JS代码上传至EdgeRoutine，即可在全球的CDN边缘节点上运行，相当于用户在全球各地拥有了大量微型服务器去就近地服务各地的用户。
下面详述下EdgeRoutine的工作原理。首先，打开一个CDN服务器，其中的请求处理流程是：原来纯CDN链路对应的1、8、9、4链路。客户端后CDN网关会去找缓存，如果找到会response给客户端。如果没有找到，会回源请求，之后存到CDN缓存并返回给客户端。
这样的链路在有了EdgeRoutine后会有什么变化呢？主要有这四种情况：
1.ER内JS代码完成对请求的计算&处理，返回给客户端：1→2→3→4
2.ER发出子请求从其他云服务获取数据后加工：1→2→5→3→4
3.ER从Cache、KV读取或存储计算后的结果用以复用：1→2→6→3→4
4.ER可主动Proxy回CDN回源链路： 1→2→7→8→9→10→3→4
EdgeRoutine的适用场景
一、在边缘图文页面渲染
左侧是两种比较常见的前端渲染的架构，一种叫CSR，在客户端去做渲染，一种叫SSR，在服务器端去做渲染。而这两种前端渲染了传统传统架构的话都有一些缺点。比如像第一种全部在客户端做渲染，需要由客户端去发起N个独立请求，去请求中心大资源就在客户端去渲染成一个HTML的页面。这样的方式是比较考验客户端性能，同时因为发起了多个异步的请求，这多个请求的延时可能就不太可控。第二个SSR全部在服务器端做渲染，客户端只要发一次请求就可以了，由服务器端去拉取相应资源，最后渲染HTML页面给到客户端。相对于CSR，SSR的中心服务器压力比较大，成本较高，同时在服务器做渲染的过程当中，客户端需要做等待，可能会影响用户体验。
有了EdgeRoutine，在边缘图文页面渲染，可以将SSR从中心服务器下沉到了边缘节点之上，下图右侧，当客户端发起一个请求，请求就直接在边缘上实现SSR渲染的过程了，好处是不依靠客户端性能，同时由于CDN节点全球的广泛分布，节点压力比较小，还可以获得更低的延时，另外也能够减少重复计算。
二、店铺小程序，类似Combo
下图左侧传统的架构中，当客户端请求过来，服务器上会根据这个请求去把通用的官方模板以及对应用户的个性化三方模板进行一个Combo，Combo成一个店铺小程序的整体框架，最后返回给客户端。其实和SSR类似的是客户端需要等待服务器端的这样过程，会影响用户体验。右侧新方案中，EdgeRoutine将Combo的逻辑放到边缘节点上面去进行，通用的官方模板可以直接缓存在CDN里面，以此减少回源站请求的耗时，通知部分请求可以直接复用Combo的结果，减少重复的Combo计算，进一步降低延时。
三、源站健康状态检查
当用户有多个服务器源站时，就需要一套操作系统来实时、持续监测全球各地来访问源站的可用性。EdgeRoutine直接运行在CDN上，所以EdgeRoutine天然是部署探针服务的一个载体，探针代码在下图右侧中，直接部署在EdgeRoutine上，实时访问源站的情况，并且收集健康信息并回传，以此达到模拟用户并实施的监测服务器可用性的目的。
除此之外，EdgeRoutine可以适用于A/Btest、IoT场景数据清洗、GEO打点，甚至托管个人站点等各类场景，既具备CDN的弹性调度、低成本、低延时特性，同时兼具Serverless简单易用的特性，具有非常大的想象和应用空间。
EdgeRoutine的核心价值
总体来说，EdgeRoutine具备CDN的弹性调度、低成本、低延时的特性，同时也兼顾Serverless简单易用的特性。
一、弹性调度
部署在EdgeRoutine的JS代码将运行在遍布全球各地的CDN节点上。用户的请求将就近访问CDN节点。当某个区域用户请求突增，CDN系统会将请求调度至周边节点，自动弹性扩容，用户无需为每一次可能的业务突增而担心计算资源不够的问题。比如下图左侧的示例，当杭州用户发起请求，就近调度至杭州的CDN节点；当杭州用户的请求突增，调度自动将请求分散调度至杭州周边的嘉兴湖州等区域的CDN节点；而杭州用户的请求进一步突增，调度自动将请求分散调度至更远的无锡上海等区域的CDN节点。阿里云CDN有2800+节点遍布全球，形成一张巨大的调度网络，自动弹性调度。
二、低成本
我们看一下计算的发展史，其实从某种维度来看的话，是对资源的隔离和复用的一个发展史。最早的物理机，到一台物理机被隔离成N台的虚拟机，再到云计算及容器化技术，虚拟机上又可以隔离出N个不同运行环境，整个过程中，用户隔离不断细化，单位硬件设备能够做到更高复用，将资源复用做到极致，给用户带来性价比更高的按量付费服务。这也是EdgeRoutine能为大家带来更低成本的价值的原因。
三、易用（Serverless特性）
传统的应用搭建的流程，用户需要去购买服务器，还需要去运维上面的系统，然后才进行整个开发应用的部署，持续去优化服务性能，需要非常庞大的团队协同。Serverless意味着用户不需要再去关注底层的基础设施，只需要关注核心的业务代码，上传你的代码就完成了整个部署。后端的这些资源是完全自动、弹性伸缩的，可以帮助用户原来缩减运维成本。基于EdgeRoutine的应用构建方式也是如此，只需要在第一次使用时候进行简单的安装配置，即可专注开发业务代码，直接上传部署即可。
四、超低延时
在边缘上直接去处理客户端的请求，跟在中心处理，肯定是会大幅缩短网络链路，这样减少了网络传输的延时风险。同时，EdgeRoutine采用Chromium V8轻量隔离技术，冷启动时间几乎可忽略。
