在全球业务拓展的浪潮下，企业追求全球化不仅意味着市场的扩张，也代表着技术实力的较量。边缘容器云作为企业实现全球战略的重要支撑，正在被越来越多富有远见的企业所采用。它们依托于边缘容器云的技术，将应用部署于世界各地，以期在保证极致用户体验的同时，实现敏捷响应市场变化。透过边缘容器云，这些企业得以突破传统数据中心的限制，克服地理和网络延迟的挑战，顺应全球数据治理的趋势，从而在复杂多变的国际市场中抢占先机，提升其竞争力。
近日，第十四届亚太内容分发大会在北京召开。阿里云技术专家邓茜在峰会上发表演讲，以《超大规模边缘容器云助力应用全球化部署》为主题，分享了阿里云超大规模边缘容器云如何帮助企业在全球拓中快速部署全球化应用。
为什么在已有强大中心云算力的情况下，企业仍需边缘云？
通常大家比较熟悉的一种部署模式就是云、边、端这三种层次，那么有了非常大的算力存储的中心云为什么还需要边缘云呢？在这种云端部署的模式下，我们也可以看到客户会面临非常多的问题。
首先从网络层面来讲，云端的网络延迟和抖动都是非常大的。如果我们把所有的算力都集中在中心，那么中心云将会面临非常大的并发，资源的挑战还有资源的成本也是非常高的，我们是否可以把这个算力往终端去做移动，终端主要一个特点就是算力非常小，可以用的计算、存储这些资源都是非常有限的，比如玩游戏的时候玩不了多久手机就会发热。还有一个思路企业是否可以自己构建一个比较自用的边缘云，首先边缘的规模非常小，而且分布也是非常的广，如果每个企业都走这种自建的模式它的周期非常长，而且没有办法保证边缘云的利用率，因此才有了我们边缘云。
边缘云我们的目的主要就是去做一个非常大面积的覆盖，给用户提供这种低延迟的服务，主要提升用户使用的效率，算力交付的效率，降低企业用户计算的成本，给用户来更低延迟，更高效的体验。
总体来说，阿里云边缘云就是一朵有大规模的地域分散的边缘节点相互协同组成的一朵可以远程管控、安全可信、标准应用的分布式云。
- 边缘云作为一种部署模式，旨在解决中心云部署模式下的网络延迟和抖动问题。
- 边缘云通过大规模覆盖提供低延迟服务，提升用户使用效率和算力交付效率，降低企业计算成本。
- 阿里云边缘云是一个由大规模地域分散的边缘节点组成的分布式云，具有远程管控、安全可信、标准应用的特点。
边缘云节点规模巨大，如何纳管底层异构资源？
首先看一下边缘容器云整体的分层结构，可以从下往上看，在最底层的是我们自建CDN的节点，ENS的节点或者是一些第三方接入的节点，它的形态主要有物理机、VM、ARM阵列。通过容器云纳管可以把所有底层资源做一个并池云化，在这个基础之上我们再提供统一的计算、存储、网络、安全、管控这些能力。
在这个边缘节点服务 ENS基础之上提供PaaS平台的能力，主要利用容器云的平台去做边缘应用的托管，边缘的镜像服务、网格等这些基础的能力，在这个基础之上再去对接OpenAPI去对接控制台提供给用户来使用。
刚才提到了边缘云节点的规模非常巨大，我们如何纳管这些底层异构资源呢？整个边缘云集群的架构是一个两层的分层的架构，最底层是真实物理节点资源，纳管这些物理节点资源的集群我们称之为边缘的管控集群，那这些管控集群也和物理资源比较类似，是分布在全球各个大区的，分布非常广。
在此基础之上，最上层提供给用户的租户集群是用户可见的集群，每一个租户集群可以实际使用的底层资源其实是刚才提到全球所有的边缘节点，每个用户可以看到的也是这么多个节点，用户可以在租户集群里面提出一些具体的部署需求。比如说我想要在全球范围内部署多少个副本，要调度到全球范围内不同的城市，提出这些资源部署需求之后，通过中间全域融合调度还有同步生产的体系，就可以把这些真实用户的应用分布到底层实际的全球各地的节点上面去。
- 边缘容器云的分层结构包括自建CDN节点、ENS节点和第三方接入节点。
- 提供统一的计算、存储、网络、安全、管控能力，并在此基础上提供PaaS平台能力。
- 边缘云集群架构采用两层分层，底层是物理节点资源，上层是用户可见的租户集群。
- 通过全域融合调度和同步生产体系，可将用户应用分布到全球各地的节点上。
如何提升大规模边缘节点的管控效率？
我们在针对这些不同的边缘节点管理的时候也做了一些非常多的策略提升管控的效率，首先就是这个边缘节点资源接入的时候我们会去请求一个资源管理中心，这个资源管理中心会做统一的集群规划还有配置管理，最后把边缘节点注册到管控集群里面去。
在这个基础之上，因为我们边缘节点分布广也会遇到非常多的问题，比如说在不同的海外节点、国内节点他们的网络环境会遇到非常多的差异，甚至是底层的环境也有非常多的差异。如何保证管控有效性呢，首先在Node接入的过程中会去做一些动态探测的逻辑，我们有非常多的边缘集群，具体这个边缘节点要接入到哪个边缘集群会做一个动态的探索和规划，以提升边缘集群的利用率。因为边缘和集群之间会有非常多可能有一些网络的抖动，我们也添加了很多边缘自治的策略，做一些断网的防护，不会因为短暂的一些断网的情况把用户的应用清除掉。
其实边缘Node网络环境是最未知的，它可能是一些国内外小运营商等等，它和边缘管控集群之间的网络我们也通过自家的产品做了一个四层的动态加速，保证这个集群和Node之间的通信是通畅的。和别的一些中心提供的基础的服务之间我们也是全域都走了自家的CDN进行加速，保证边缘和中心的管控之间通信是非常流畅的。
边缘节点可能会产生一些异常的情况，需要有一些运维和监控的能力，我们在每一个边缘Node上都会去部署一个边缘的监控agent，实时地上报心跳，采集边缘监控的数据，和下发一些运维的动作。
- 边缘节点资源接入时，通过资源管理中心进行集群规划和配置管理。
- 动态探测逻辑确保边缘节点有效接入最合适的边缘集群。
- 边缘自治策略和四层动态加速保证集群和边缘节点之间的通信通畅。
- 边缘节点上部署监控agent进行实时监控和运维动作。
如何加固边缘容器云管控的稳定性和进行异常诊断？
接下来我再介绍一下我们针对于在实际的边缘容器云这个集群管控的过程中遇到的一些误删等异常操作或异常事件做的一些稳定性的加固。我个人感觉非常有用的一点就是我们的风控系统。风控顾名思义就是做一些风险的控制，比如说人为的误操作或者是因为软件的异常会触发一些误删除的动作，我们的风控系统其实是可以让用户自主的去配置一些风控的策略。比如说我在一段时间内我不允许任何破的有删除或者在30分钟之内我只允许删除一个副本，类似的这种风控策略，可以有效的保证在用户不允许删除任何资源的情况下，你的应用可以非常平稳持续运行在我们边缘云的平台上。
整个边缘容器云的平台里面每天都会遇到非常多异常问题，比如说边缘的Node系统异常、磁盘异常或者网络异常等等的问题，这么庞大的系统如果都人工去处理的话，对我们来说人力的消耗是非常难以接受的，所以我们也构建了一个异常诊断的系统，这个诊断系统会实时监控Node的这种异常状态，再去做一个异常的诊断。
这个异常的诊断可能会去请求一些中心的接口或者边缘的接口，去获取一些不同组件的运行日志，最后会根据当前各种异常的情况做一个根因推导，最后根据推导结果和提前的预设流程会去做一些自动化运维的动作，做自动化的恢复。
如果恢复不了的话再告警到人工去进行处置，异常诊断系统每天可能会有上万次的诊断和上千次自动运维的动作，非常有效的节省了运维人力。
- 风控系统允许用户配置策略以防止误操作和误删除。
- 异常诊断系统实时监控Node异常状态，进行诊断和自动化运维动作。
阿里云边缘容器落地实例
云游戏和机顶盒流化场景：
首先云游戏和机顶盒等终端轻化场景是一个典型场景，其中边缘终端的能力与资源受限。通过将计算任务卸载至边缘节点，利用边缘节点，我们可以把用户与节点间的延迟控制在10毫秒以内，极大地提高对实时性要求苛刻业务的支持。这得益于阿里云丰富的硬件资源，包括多样化的板卡和GPU设备，可以用于加速终端计算，提升用户体验。
域名级别的API服务：
第二种比较典型的应用场景就是通过边缘的Serverless技术提供域名级别的API服务。一般域名服务集中部署于中心节点，但部分计算任务适宜分布式部署，无需全部集中化。我们可以将这些任务直接分布至边缘节点，使服务更接近用户。
借助边缘容器云平台，我们在部署完应用后，可以为其自动绑定公网IP对外提供服务，通过域名系统绑定IP和DNS解析实现流量调度。
这得益于我们在CDN领域的深厚经验，我们能够对用户的域名进行精确的流量分配，消除了用户自行管理各个节点和公网IP的复杂性。
日志预处理：
另一个边缘云应用示例是日志的预处理。通常边缘设备会生成大量运行日志，这些日志需要传回中央服务器处理，而日志数据的带宽需求很高。通过在边缘设施部署处理逻辑，可以对日志进行清洗、压缩和预处理。
这一预处理后的数据再传输至中央服务器，显著降低了边缘云与中心云之间的数据传输带宽消耗，从而减少成本。由于带宽价格昂贵，这种做法既节约了中心服务器的宽带资源，又缩短了末端到边缘的传输距离，提升了日志上传效率。
这得益于我们利用CDN节点提供服务，可以充分利用CDN下行带宽成本高但上行相对便宜的特点，节省额外成本，实现中心带宽成本的有效节约。
全链路压测场景：
最后一个例子是全链路压测场景，其目标是模拟大规模用户活动，特别是在大规模促销活动中快速生成海量边缘终端模拟请求。这些模拟请求用于对中心服务器进行压力测试。CDN节点因广泛分布且与用户位置接近，能够有效地进行此类端到端的模拟。
压测任务本身也可进行时间优化，即在网络非高峰时间段执行，以节省带宽和计算资源消耗。对CDN而言，这样的调度可以有效减少成本负担。
