解读 | 基于CDN的边缘计算平台设计和思考

导语

CDN的重要性不仅仅在于CDN的业务本身，更重要的是CDN的基础设施属性，CDN节点是全球分布的，随着5G的正式商用，目前来看，CDN的规模最大、算力最强，将成为布局边缘计算最佳的位置。但是边缘计算不是孤立存在，是必须跟云中心协同的。本文介绍从CDN的角度思考如何打造一个云边端协同的边缘计算平台。

CDN和边缘计算

CDN的全称是Content Delivery Network，即内容分发网络。CDN是构建在现有网络基础之上的智能虚拟网络，依靠部署在各地的边缘服务器，通过中心平台的负载均衡、内容分发、调度等功能模块，使用户就近获取所需内容，降低网络拥塞，提高用户访问响应速度和命中率。CDN的关键技术主要有内容存储和分发技术。

以上是来自来自百度百科的解释，简单的说CDN就是用空间换时间，空间的话就是分部在离终端用户较近的边缘节点，时间上就是终端用户直接从边缘节点直接获取资源，这样就不需要直接访问源站，从而提升用户体验。

举一个不是很恰当的类比，比如现在国内电商平台建立物流系统：在一城市会建一二个大型物流中心（源站），三四线城市会建立小型物流中心（边缘节点），像双十一这种大促，会根据大数据统计算提前在各地的小物流中心准备好商品（预热），这样用户就可以快速获取包裹（就近获取）。所以CDN可以认为是目前整个互联网的物流系统，只不过CDN分发的不是包裹，而是图片、视频、软件安装包。一般一家CDN服务商需要有成百上千个边缘节点，才可以具备比较好的服务质量。

CDN已经是一个充分验证过的成熟技术，可以不夸张地说，CDN扛住了整个互联网大部分的流量，没有CDN就没有现在繁荣的各种视频网站、直播平台和小视频APP。同时经过长期的发展，CDN在供应链体系、节点建设、网络运维都有非常成熟的经验和沉淀。

随着互联网智能终端设备数量的急剧增加，以及5G和物联网时代的到来，传统云计算中心集中存储、计算的模式已经无法满足终端设备对于时效、容量、算力的需求。将云计算的能力下沉到边缘侧、设备侧，并通过中心进行统一交付、运维、管控，将是云计算的重要发展趋势，这个就是边缘计算。

IDC预计，到2020年全球将有超过500亿的终端与设备联网，超过40%的数据要在网络边缘侧进行分析、处理与存储，这对边缘计算提供了充分的场景和想象空间。

边缘计算分层结构包括云、边、端：

云，Centralized Cloud：传统云计算的中心节点，资源丰富，计算力强，扩展性强，服务多区域，但离终端用户远。同时云中心是边缘计算的管控端，负责全网算力和数据的统一管理、调度、存储；

边，Infrastructure Edge：通常服务特定的一个区域，如市、县、区等，部署在目标服务区域10～30公里的地方，提供满足目标服务区域的计算、存储、网络服务。Infrastructure Edge边缘通常位于IDC内，拥有充足的算力和存储容量，和中心有专线或骨干网连接，如CDN节点等。Infrastructure Edge又可分为Access Edge和Aggregation Edge两层，其中Access Edge靠近Device Edge，与用户或设备端更近，Aggregation Edge聚合一个或多个Access Edge的数据，与云端进行交互。

端，Device Edge：终端设备，如手机、智能家电、各类传感器、摄像头等。

可以认为CDN是边缘计算的一种形态，并且是当前来看规模最大、算力最强的形态、也是成熟度最高的业务形态。但是CDN的业务形态也需要做技术架构升级，才能支撑更多的边缘计算场景。

边缘计算的技术形态

边缘计算技术形态也可以按照传统的逻辑划分为IaaS、PaaS和SaaS：

IaaS：在边缘测提供虚拟机，这个跟在云中心购买ECS差不多，只不过机器是部署在边缘IDC（这里的边缘IDC其实是相对于云中心IDC），但是在网络情况和稳定性上是跟云中心不一样的，毕竟云中心有几万台机器的规模冗余，有专门的驻场人员、机房和网络维护，而边缘节点有时候是不具备这些条件的，但是在使用场景上肯定也是不一样的，比如：不建议在边缘部署对数据可靠性要求非常高的业务。

PaaS：提供虚拟机的方式对于有些用户来说，可能运维起来有点麻烦：比如机器是分部在不同地方和不同运营商的，各地的网络不大一样，机房也有网络割接的时候，管理这些虚拟机也会有不小的成本，难以快速进行业务切换调度。这样一来就需要有个边缘场景的PaaS服务，来帮助用户管理和调度边缘的资源，容器和K8S的话是一个在运维调度层面很好的解决方案。在解决运维的问题后，用户对于PaaS的需求也会上升到更加多样的能力，特别对于各种中间件的需求，EdgeKV，EdgeStore等等，比如KV需要具备全网数据同步的能力。

SaaS：CDN就是典型的SaaS服务，主要包含包含静态文件（文件、图片、视频）加速、流媒体加速、动态加速，衍生的形态还包括安全、P2P。另外视频AI也是后续一个重要的SaaS能力，比如自动驾驶、IOT场景的一个重要需求就是需要在边缘能够直接进行视频AI处理来保证延时。

可编程CDN：除了往通用计算转型，CDN的一个重要方向是往可编程CDN转型，简单的说就是通过函数计算或者脚本来控制CDN逻辑，比如Cloudfare的EdgeWorker，在边缘支持V8引擎来运行JS脚本，这种技术方案相比于容器的优势在于更加轻量级、成本更低、启动时间更快。

可以看出边缘计算并不是孤立存在的，边缘计算一定是需要跟云计算进行协同，所谓云边端协同。

一种比较形象的说法：如果把云计算比作整个计算机智能系统的大脑。那么边缘计算就是这个系统的眼睛耳朵和手脚。完全依赖云计算的计算机系统就好比每一件事都要请示司令部的军队，在需要大量和外界互动的时候会显得僵化，反应迟缓，而且一旦网络有点问题就彻底歇菜。加上边缘计算之后就好比让中低层军官也开始发挥主观能动性，能一定程度上自主做出智能判断和行动决策，同时也只需要把一部分经过筛选的信息上传到司令部。大大缓解了网络通讯的压力。即使在和总司令部暂时失去联系的情况下，也能自主做出部分决策。

边缘计算跟云计算相比也面临着诸多挑战，以CDN为例，边缘节点分布广，单节点规模小（1～100机器左右），大部分节点是没有驻场人员，所以维修周期长（1～2周）。同时节点的网络复杂并且不可控，网络割接、运营商封禁是常有的事情，省与省，国与国（海外）之间都有种非常复杂的调用链路。

面对这些问题，就需要对 调度/容灾能力、运维能力要有比较高的要求，CDN本身的业务形态就是天然容灾和可调度的：一个节点挂了，流量就可以切换到其他节点上。CDN节点架构也相对比较简单，经典三层架构：四层负载均衡（LVS）+七层负载均衡（Nginx或者HaProxy）+缓存服务（Squid），所以CDN运维也是比较简单的，机器上主要是缓存数据，机器挂了整体影响不大，不需要做数据迁移。

但是CDN要转型到通用边缘计算平台，调度/容灾能力和运维能力就会变成规模化的一个主要瓶颈，怎么做调度、怎么做容灾、怎么做运维，这些问题在边缘场景更加突出。

因此容器的轻量级和DevOps属性，加上Kubernetes的调度，目前看来是非常是非常适合边缘计算。

容器在边缘计算的落地形态

容器和Kubernetes的落地场景主要还是在中心大集群场景，目前在边缘的落地形态也是在探索和实践中，目前针对边缘场景的Kubernetes有：

K3S：K3S是Rancher开源的轻量级Kubernetes发行版，K3S是通过大量裁剪Kubernetes代码，只保留主要核心代码，这是是为了在边缘计算环境中运行在x86、ARM64和ARMv7处理器上的小型、易于管理的Kubernetes集群日益增长的需求。可以看出K3S主要是适配端（Device Edge）上的场景，通过简化Kubernetes来保证可以运行在终端设备上。

KubeEdge：KubeEdge是华为贡献给开源社区的一个项目，从名字上可以看出也是真的边缘场景， KubeEdge的优势在于设备连接，它可以支持多种协议，并使用基于标准MQTT的通信，这有助于有效地使用新节点和设备扩展边缘集群。KubeEdge主要的场景在于边缘接入层（Access Edge），解决各种IOT终端设备接入的问题。

ACK@Edge：ACK@Edge是阿里云ACK（Kubernetes）适配边缘的形态，ACK@Edge在实现上保存了原生Kubernetes的所有能力，所有边缘相关的特性均通过Addon实现，Master是部署在云中心，Node在边缘端。ACK@Edge比较适合基础设施边缘（Infrastructure Edge），比如CDN场景。

以CDN场景的落地场景来说，形态上就是在云中心部署Kubernetes Master，将云中心所在Region附近的CDN节点接入到Kubernetes中，最后Kubernetes之上构建Fedration能力，进行全局容器调度。这样就能利用Kubernetes调度能力和容器的DevOps能力。具体可以参考https://yq.aliyun.com/articles/711767。

未来展望和趋势判断

CDN转型边缘计算平台，CDN已经是一个非常成熟技术和业务，也是因为成熟，所以同质化严重，同时因为CDN的业务粘性不够（改个DNS业务就切走了），所以目前国内CDN的商业环境并不是太好，CDN行业变成价格红海，所以CDN厂商也纷纷在进行战略转型边缘计算平台，但是5G还未大规模商用，转型之路面临着诸多问题：落地场景存不确定因素，客户接受程度不够等等。但是改变可能失败，不改变必定掉队，所以当务之急是先修炼好内功，把新技术（虚拟化/容器/AI）在CDN进行落地和磨炼，同时积极挖掘各种新业务和场景。

安全容器是重要能力，容器天然适合边缘计算，但是容器也是比较大的硬伤，那就是安全和隔离，这也是为什么现在边缘计算的主要对外售卖形态还是虚拟机。所以安全容器就是一个最佳解决方案，具备容器的DevOps属性，又有比较好的隔离和安全保证。今年Kata安全容器发展迅猛，所以安全容器是边缘计算的一个关键技术。

视频AI和边缘计算天生一对，视频AI目前已经有不少落地场景：人脸识别门禁、自动垃圾分类、食堂自助结账等等，可以预见视频AI将会继续快速发展。但是随着规模的扩大和场景的挖掘，视频AI对于低延时的需求会日渐强烈，如果能把视频AI能力部署在边缘节点上：云中心进行大数据计算和AI训练，AI训练结果下沉到边缘节点，边缘负责视频接入，直接在边缘进行处理。

Q&A

Q：能否介绍一下，目前CND节点改造成边缘计算节点，主要涉及哪些方面改造，阿里的实践情况，谢谢。

A：目前CDN改造有3个部分：基础设施到改造（交换机、机型），软件层面的改造（容器化），CDN节点架构的改造（比如把传统的7层负载均衡改成Kubernetes的Ingress Controller）。

Q：CDN场景的落地场景来说，形态上就是在云中心部署Kubernetes Master，将云中心所在Region附近的CDN节点接入到Kubernetes中 ，指的是在各个Region里面的节点当作Kubernetes的Node处理吗？

A：比如我们在阿里云中心的杭州Region创建一个Kubernetes Master，然后会把杭州整个省的CDN节点，全部接入到这个Kubernetes Master里面，CDN节点指的是一个机房，一个机房会有1～100台机器，整个CDN节点的机器都会接入。

Q：请问阿里边缘计算有和5G结合的计划吗？具体有哪些结合点？

A：在今年云栖大会上，我们已经发布了5G边缘计算战略，这个可以网上找下视频回放。具体的结合点目前来看是城市大脑和城市云。不过因为5G还未大规模商用，所以我们也在探索。https://yunqi.youku.com/2019/hangzhou/review?spm=a2c4e.11165380.1395223.1

Q：请问未来Docker会向安全容器转型吗？安全容器是趋势，作为开发者要注意哪些点？

A：其实Kata和普通runC容器，在行为上没有太大差别，如果非要说关注点的话，目前我觉得是内核部分，因为Kata容器对于内核要求是比较高的，稳定性方面还需要打磨。

Q：在云上部署Kubernetes Master节点，CDN节点作为边缘节点。对Kubernetes来说，节点之前的网络通讯要求会比较高，那当网络不稳定时，边缘节点和Master节点断开，这时如何实现边缘节点上的服务自治呢？

A：这个就是ACK@Edge解决的问题了，ACK@Edge在边缘测机器上部署了一个Edgehub的组件，kubelet并不是直接请求kube-apiserver，而是通过Edgehub然后再请求到APIServer。Edgehub做了缓存和代理的能力，即使在断网的情况下，也能保障边缘节点的kubelet正常工作。这个能力叫做边缘自治，是ACK加强的能力。

Q：请谈谈阿里看到的边缘计算cover的真实价值场景或者客户群，感觉很多现有场景中心计算也能满足，不一定要用边缘计算。特别是边缘计算节点也卖虚机，价值不大。谢谢。

A：以CDN为例，CDN就是通过边缘做加速来提高用户体验。虚拟只是一种形态，比如你购买虚拟机自建CDN。所以边缘的场景肯定是跟中心不一样，比如城市大脑，就是需要在就近有个节点可以做接入，如果全部回中心，对中心的压力也很大。

Q：请问安全容器的存储性能有考虑过么？接入点在边缘还是放云端？

A：安全容器最终是跑着边缘上的，安全容器的存储目前是一个大的问题，Kata开源的存储方案性能并不好。阿里云的内核团队做了大量的优化，目前应该有了比较大的性能改进。

Q：容器安全方面有什么需要注意的？除了Kata之外，使用dockerd与Kubernetes有什么安全建议psp之类的？

A：安全容器的使用，第一Kubernetes需要做适配runtimeClass，第二内核也要求比较高（应该是要4.*内核比较稳定）。安全建议：就是加证书、改端口，不然容易被外部注入容器。其他的安全建议：就是直接使用云上产品，云上产品具备了比较高的安全能力。

Q：CDN的流量分配是在哪里做的？是DNS还是GSLB那种？异地灾备也可以用同样的方式？

A：CDN的流量分配就有DNS、HTTPDNS、302调度，CDN本身就是成熟的技术了，调度这块都是非常成熟的技术。

来源：架构师技术联盟

免责声明：本文系网络转载，版权归原作者所有。但因转载众多，或无法确认真正原始作者，故仅标明转载来源，如涉及作品版权问题，请与我们联系，我们将在第一时间协商版权问题或删除内容！内容为作者个人观点，并不代表本公众号赞同其观点和对其真实性负责