阿里云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的来临和边缘计算的发展,能够让产业互联网有更大的发展,让我们不曾想、未曾做的事情得以实现。”

文章只代表原作者观点,边缘云致力于打造独立、客观的资讯信息平台,转载请注明来源于边缘云信息平台。
分享到
长按二维码关注

参与讨论 抢沙发

评论前必须登录!

立即登录   注册

边缘云生态研究

关于我们