阿里云CDN和ENS边缘云原生技术体系建设之路
Posted ITPUB技术小栈
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了阿里云CDN和ENS边缘云原生技术体系建设之路相关的知识，希望对你有一定的参考价值。
CDN正在进行二次变革，从以内容分发服务为主转变为边缘云平台，转型之路任重而道远，好在随着以容器、Kuberentes、ServiceMesh为主的云原生技术的成熟，提供了方向和思路。边缘计算遇上云原生，为此从2019年开始阿里云CDN团队开始了CDN容器化改造工作，同时逐步沉淀出阿里边缘云基础技术平台，输出技术能力输出到边缘计算ENS场景，真正意义上实现CDN转型边缘云。
在10月22日的SACC2020中国系统架构师大会上，阿里云技术专家吴龙辉进行了《边缘计算遇上云原生 - 阿里云CDN和边缘云原生技术体系建设之路》主题演讲，从CDN和边缘计算的关系、CDN容器化的挑战和技术方案、阿里边缘云原生技术体系建设概况等方面进行技术解读。
阿里云技术专家，《Kuberentes实战》作者，致力于云原生技术的研究，拥有丰富的云原生和容器化实践经验；目前负责阿里云CDN和边缘云原生技术体系建设，包括边缘容器平台研发、CDN容器化等。
一、阿里云CDN和边缘计算ENS
阿里云CDN诞生之初主要是为了服务于淘宝主站，2014年开始对外商用，发展至今，阿里云CDN已经成为中国国内最大的CDN服务商，目前阿里云CDN在全球有超过2800个边缘节点，单节点带宽超过40Gbps，全网带宽输出能力130Tbps。
阿里云CDN支持多种行业、多种场景内容加速，例如：图片小文件、大文件下载、音视频点播、直播流媒体、全站加速、安全加速等等。
边缘计算是这几年才提出的一个概念，首先边缘计算是相对于云中心计算而言的，边缘是一种分布式的计算架构，将应用程序从云中心节点移往边缘节点去处理，将原本完全由中心节点处理的服务加以分解，分散到边缘节点去处理。边缘节点更靠近于用户终端，可以加快数据的处理与传送速度，减少延迟。
CDN是一个已经发展20几年的技术和行业，业界对于CDN和边缘计算的关系也有比较一致的认识：CDN是广义边缘计算已落地的最大规模业务，通过边缘节点分发内容，使内容更贴近用户，有效改善用户体验。
今天讲CDN不仅仅在于CDN的业务本身，更重要的是CDN的基础设施属性，CDN节点是全球分布的，随着 5G 的正式商用，目前来看，CDN 的规模最大、算力最强，将成为布局边缘计算最佳位置。
2017年 阿里云内部就已经开始看到了边缘计算的价值，将阿里云飞天操作系统在CDN边缘节点落地，并且通过阿里巴巴集团内部业务进行孵化，随后即正式发布ENS1.0服务。ENS是边缘节点服务（Edge Node Service）的英文简称，简单说ENS是基于CDN的边缘节点和网络构建的，提供靠近终端用户、弹性的边缘算力资源，通过ENS可以帮助用户业务下沉至边缘，有效降低计算时延和成本。
在2019年的云栖大会上 阿里云对外发布了ENS2.0，开始将CDN和ENS的技术进行深度融合，一方面CDN的通用化核心技术（包括存储、网络、安全、中台等等）下沉到ENS，成为ENS的一部分能力，另一方面，CDN业务逐步变成ENS上的一个租户。通过ENS和CDN的融合，我们也在持续赋能给我们的用户，进行各种行业和场景落地。
目前在ENS的服务平台上，已经承载了大量CDN业务，以及一大批直播平台的边缘收流、合流、互动、弹幕等业务。而现在火热的在线教育、智慧办公、智慧医疗等行业核心依赖的音视频通信技术，也因为其低时延、大连接、大带宽等需求特点，陆续成为使用ENS的重要场景。
随着各种业务场景的持续打磨，ENS也形成非常强大的产品能力：
第一，ENS支持支持多种计算形态：除了虚拟机，也支持Kubernetes标准的容器和安全容器形态。
第二，ENS支持多种存储和网络服务。
第三，ENS在安全和运维自动化上提供全栈技术能力，帮助用户快速方便、并且安全稳定地落地边缘计算场景。
二、CDN容器化
在介绍CDN容器化之前，先对比一下CDN相对于中心云所面临的技术挑战：
在机房分布方面，CDN的机房是全球分布的，这对于机房建设挑战是非常大的，比如是边远地区的机房，维修周期是以周为单位的。
机房规模方面，CDN每个机房规模是比较小的，相比云中心机房上万甚至百万机器的规模，边缘机房是非常之少（几十/几百台），这对于业务的容灾保证是比较大考验：如何在有限机器下保证冗余和异常迁移。
流量调度方面更不需要说了，调度能力是CDN核心技术，如何保证业务质量、成本和水位，一直都是CDN的技术挑战。
运维管理方面，相比于1～3中心，边缘成千上万节点的管理，运维成本是几何倍数增长的。
弹性方面，因为单机房资源少，所以在业务弹性的时候往往要弹性到其他节点上，这种扩节点的弹性，对于业务本身也需要提供很多支持，比如跨节点数据同步、服务发现等等。
网络方面：边缘节点的网络是不可靠的，机房割接、网络异常、网络攻击是常有的事情，网络异常下就面临业务容灾、边缘自治等等的技术挑战。
存储方面：在成本和节点规模的限制下，目前边缘节点其实并没办法提供完全的数据持久化能力，那么边缘节点数据如何和云中心进行同步，就是一个关键问题，哪些数据可以放在边缘，哪些数据需要传回并存储在中心。
资源异构层面：CDN导致机型众多，机器能力不一致。另外也提出过CDN on Anywhere的目标，包括MEC节点，合作节点等等，节点环境的差异巨大，对安全和管理都是比较大的挑战。
从ENS2.0开始阿里云将CDN和ENS的技术进行深度融合，其核心的目的是为了将CDN从以内容分发服务为主转变为通用边缘计算平台，其中的一个核心技术方案就是 CDN容器化。
CDN容器化的价值主要有几点：
第一，跟大部分业务容器化一样，CDN容器化主要也是要解决自身的问题：
成本方面：通过业务混部优化建设成本，支持CDN轻量级节点；
效率方面：通过容器的Devops能力优化运维架构，提高效率；
稳定性方面：通过业务拆分隔离，减少业务之间互相影响
第二，CDN容器化更重要的战略意义是通过CDN容器化后，CDN跑在了ENS之上，一方面CDN资源释放给ENS，另一方面CDN的通用能力能够下沉到ENS。
在执行层面，主要从3个步骤推进CDN容器化：
第一步是平台升级
CDN容器化主要采用的Kubernetes来进行容器编排，ServiceMesh进行组件之间的服务发现，所以需要开发一套PaaS平台，能够管理和发布CDN容器，并同时兼容已经具备的运维能力。
第二步是组件容器化
需要针对CDN的组件进行容器化后的功能/性能验证，组件容器化接入Kuberentes后，也针对一些场景进行微服务改造，以支持组件混部后的服务发现。这部分更多的是验证和优化，找出组件容器化需要改造的地方。同时在稳定性层面，因为引入了更多的系统和风险，在可观测性和运维SRE层面需要投入比较多的精力和人力，在体系建设和技能培训上齐头并进。
第三步是业务迁移
前2步完成后就是进行CDN业务迁移，正如给飞行中的飞机换引擎，迁移过程需要对现有业务做兼容，保证平滑迁移。
通过这3步，CDN业务就顺利平滑地迁移到容器中，吴龙辉表示：“我个人的经验来说：在业务团队不熟悉容器和云原生的情况下，尽量先兼容已有的逻辑，让业务对于容器化后没有太大的变化，然后逐步优化，避免操之过急，引发故障。同时在过程中帮助业务进行优化，帮助业务去理解新的技术和理念，平台方和业务方共同推进落地。”
吴龙辉：“通过CDN容器化，我们积累了非常多的经验（坑），阿里云有个传统：自己的狗粮自己吃，新技术拿自己试验，再为对外服务，所以在今年开始我们陆续会将这些云原生的理念和技术能力注入到ENS中，建立ENS边缘云原生技术体系。”
三、ENS边缘云原生技术体系
“云原生也是一个新兴的概念，我个人的理解其实就是基于云计算技术进行应用设计开发，以充分利用云计算的优势。对于边缘云原生，我的定义是基于边缘计算进行应用设计开发，以充分利用边缘计算的优势。”
ENS边缘云原生的优势有：
低延时：ENS可以提供就近计算。
弹性能力：ENS依托于CDN，有巨大的算力资源，能够提供弹性能力和质量保证、故障迁移。
边缘自治：在断网情况下支持边缘节点内部自治，保证部分业务功能无损。
云边一体：边缘计算不是孤立存在，是必须跟云中心进行协同的，ENS能够提供跟云中心一致的能力和体验。
不变的基础设施：ENS会屏蔽边缘异构资源的差异性，给上层提供统一的Serverless能力
标准化：边缘计算是云计算的一部分，2者是统一的。
就如大家所知道的，目前Docker、Kuberentes、ServiceMesh是云原生领域的代表技术。在前面CDN容器化部分提到我们已经边缘场景落地容器、Kubernetes和ServiceMesh。
这里总结一下边缘云原生的区别和挑战：
容器调度：中心的容器调度一般是不需要考虑业务请求（流量）调度的，中心会在1～3个Region进行部署，然后通过DNS配置请求转发逻辑，这种情况下，容器都是提前调度并且部署好的（主要是资源调度），其实并不需要跟业务请求协同。而边缘很多场景下容器调度是需要和业务请求调度协同，比如业务需要在华南地区部署10个容器，这10个容器会分布在10个边缘节点，那么当容器调度到这些边缘节点后，业务请求也需要调度过来，而且当某个节点故障后，容器迁移到其他节点，业务请求也需要同步调度过去。业务请求调度可以复用CDN强大的流量调度能力，同时容器调度需要和CDN调度深度协同，这是中心不具备的能力，也是边缘场景下需要深入打磨的核心能力。
Kubernetes：目前Kuberentes的大部分都是在中心场景下落地，一般来说一个中心会部署完整一套Kuberentes，Kuberentes的Master和Node都在一个私有网络/VPC内，Kuberentes单集群能管理5千～1万的Node数目，其实对于大部分场景下只需要维护1～3个Kuberentes即可。在边缘场景下，目前采用的结构是Kuberentes Master部署在云中心，然后就近管理周边的边缘节点，比如部署在杭州Region的Kuberentes Master，管理整个浙江省的节点，Master和Node之间是通过公网通信；同时因为我们节点和机器比较多，Kuberentes集群数目也比较多，在全球主要的Region都会部署。
ServiceMesh：跟Kuberentes类似，ServiceMesh大多是在中心内网内工作，不需要考虑跨机房、跨公网通信能力。ServiceMesh因为涉及到业务数据面，对于数据延时和边缘自治的要求会更高。
应用/运维管理：应用/运维管理方面，边缘跟中心大部分是一致的，但是边缘场景下需要考虑多节点的发布灰度、中心和边缘的网络通信等等问题
阿里云边缘节点服务ENS边缘云原生体系建设的技术目标：
更加适合边缘的云原生能力：各种云上的技术，各种开源技术，需要针对边缘的需求进行增强，能够让用户在边缘使用各种能力，目前正在投入的方向有：Kubernetes、ServiceMesh、容器、安全容器、容器存储/网络，以及各种中间件的集成。
更加标准和通用的应用管理能力：对用户来说，应用部署云中心和边缘，只是底层环境的差别，上层的应用管理应该是一致的，标准的。这部分我们也在集成一些业界标准，包括微服务化、OAM、可观测性等等
更加稳定和可靠的边缘Serverless底座：边缘的管控和运维成本是比较高的，所以用户在边缘落地的时候更倾向于Serverless形态，为此我们需要提供一个稳定和可靠的底座。
核心能力上，包括边缘网络，边缘融合计算、边缘管控，边缘云原生体系会跟整个ENS边缘云核心能力进行集成和持续打磨，做深技术和产品，为用户持续创建价值。
随着CDN容器化的落地，以及ENS边缘云原生体系的建设，阿里云进一步提出CDN on ENS，即全网CDN使用云原生技术上ENS。
通过CDN on ENS，阿里云会把全网2800+多个CDN节点改成ENS节点，所有ENS节点除了能够运行CDN业务之外，也能够运行ENS外部业务。技术挑战上：
需要要保证CDN业务和ENS外部业务的隔离，包括运行时、网络、存储都需要强隔离以保证安全
需要在保证稳定性的前提下，CDN on ENS后成本无大幅增加。
CDN和ENS统一资源池，那么CDN的流程调度和ENS的算力调度需要时时协同，在保证质量和SLA的情况下最大化资源复用率。
吴龙辉：“在大部分CDN厂商还处在探索阶段的时候，阿里云正在进行着真正意义上CDN的技术架构大升级，这代表了我们对于边缘计算的态度和决心。边缘计算是个非常大的领域，我们想通过5G的来临和边缘计算的发展，能够让产业互联网有更大的发展，让我们不曾想、未曾做的事情得以实现。”
以上是关于阿里云CDN和ENS边缘云原生技术体系建设之路的主要内容，如果未能解决你的问题，请参考以下文章