随着企业和政府建立自己的新常态，5G和边缘计算对于提供许多行业（包括制造业，医疗保健，能源和公用事业等）所需的自动化，性能和认知洞察力必不可少。
- Forbes
一、边缘计算的发展趋势
全球产业数字化正在快速的前进，各个行业对基础设施能力提出来越来越高的要求，数字化的应用不仅需要强大的算力完成大数据分析和AI建模，还需要满足现场对处理延迟和网络条件的苛刻要求，满足高度的隐私性和安全性要求，以及能在复杂的IT环境中提供统一且一致的管理能力。
边云融合即通过边缘计算和云计算的结合，使应用具备穿越物理范畴的能力，从而使数据总能在最佳的成本、算力和隐私条件下得到处理，由此得来的知识和结论也能按需应用于不同的环境。通过将边云融合进一步与云原生思想相结合，就能够实现算力的按需调度，使设备能够在无人值守的条件下，借助AI技术自动化智能化的执行任务。
从总体来说，产业对边缘计算的根本诉求在于适配性、可编程性和可管理性。其技术趋势可以总结为如下几点：
- 环境标准，基于标准的API环境开发和移植应用程序；
- 统一编排，由单一的控制面系统管理云和边缘的应用；
- 可伸缩性，同一套架构能够支持不同性能、不同规模的设施；
- 去中心化，模糊边缘和中心的边界，实现应用和数据的全局分布式协作。
本文将深入分析边缘计算从容器化到云原生化的技术演进，进一步提升应用的敏捷性。
二、边缘计算的容器化
容器是良好的应用打包方法，使用容器可以保证应用在不同的平台开发、测试和执行均能看到相同的运行环境，从而大幅改善应用的开发敏捷性和交付一致性。
在不同的场景中，边缘计算需要使用不同的硬件和系统，也要承载不同的应用，使用容器技术就是一种直观的选择。容器化的边缘具备以下优势：
- 解耦运行依赖：非容器模式需要现在本地操作系统上安装对应的依赖库，容器模式实现了依赖封装；
- 标准化应用分发：不再依赖于不同操作系统的包管理命令，统一使用标准的容器格式和容器仓库；
- 扩展应用类型：边缘平台使用统一的容器控制面接口，从而能够支持各种类型不同的应用。
下图是LFEdge基金会开源项目“Baetyl”的1.0版本架构图，展示了一个典型的容器化边缘计算系统：
![]()
上图左侧是Baetyl的主进程，该进程位于容器外直接运行于本地操作系统上。主进程对外暴露一系列管理控制接口，将管理操作保存并翻译为Docker API原语。主程序本身不提供具体的业务功能。
上图中间位置是多个Baetyl功能服务，这些服务均以容器的形式运行于Docker内。尽管服务的具体功能、使用资源和开发语言都不相同，如Agent服务负责接收远程控制台命令并转发给主进程实现OTA升级、MQTT Hub服务负责所有模块和IOT设备的数据连接、Remote服务负责数据与第三方的对接、Function Manager提供多种语言的函数计算等，但Baetyl只需以标准容器方式启动和监控即可。
容器化提供了一系列便利，已经是今天几乎所有边缘计算产品的默认选择。但随着生产环境的部署逐渐增多，也暴露出了若干问题：
- 单机限制：Docker缺乏有效的多机通信网络，这限制了边缘的总算力规模；
- 编排限制：Docker Compose缺乏多实例和跨机器连接能力，这限制了对复杂业务的描述能力；
- 更新限制：位于容器外的主程序仍然需要手工升级，这限制了无人值守设备的普及。
- 管理限制：边缘应用的定义和管理模式与云应用分离，这限制了业务的敏捷性。
为解决上述问题，边缘计算平台开始走向与云原生相结合的模式。
三、边缘计算在本地设备上的云原生化
云原生模式的关键技术是对底层设施的切换。通过将Docker切换为Kubernetes，即改变了边缘主程序的运行方式，使其成为运行在Kubernetes之内的一个具有管理特权的容器实例，又带来了更精细的应用组织能力，从而直接引入微服务和服务网格。
下图是LFEdge Baetyl 2.0的架构图，展示了一个典型的云原生边缘计算系统：
![]()
从上图可以看出，Baetyl 1.0到2.0的升级将原先的“主程序、容器服务和远程管理”三级简化为“服务+远程管理”两级，所有本地程序都运行在Kubernetes内。这种变化将为开发者带来多方面的收益，包括：
- 可更新的主程序。在原先的模式里，Baetyl 系统本身需要使用手工或操作系统包管理器进行更新，这就势必要求操作者获得控制台。新的模式将“系统更新”看作 Baetyl OTA 的一部分，这将让边缘计算设备总能第一时间获得安全更新和Bug修复。
- 可独立更新的多容器应用。在原先的模式里，每个容器虽然是完全独立运行的服务，但升级却需要统一进行，管理员也不能定义服务之间的依赖关系。新的模式充分利用的 Kubernetes 丰富的应用定义，并且使每个服务都能被独立的部署和升级，这将让边缘计算拥有更加多样的功能。
- 对边缘集群的支持。新的模式基于 Kubernetes 的编排能力，可以让一个 Baetyl 实例分布在多个不同的计算节点上，这既能提升总的计算能力，又能获得更高的可用性。
四、边缘计算在远程管理上的云原生化
根据LFEdge的定义，边缘计算会覆盖了多种不同的网络区域，实现与云的无缝融合。
![]()
从图中可以看出，不同的网络之间并没有绝对的边缘和云的区分，而是根据各自的特点承担不同程度的计算负载，双方存在应用和数据的广泛交换。基于这样的原因，边缘计算需要与云计算共享同一套控制面机制，也就是都纳入云原生的形态范围内，统一使用Kubernetes进行管理。
Kubernetes将应用编排的操作转化为etcd中的数据条目，工作节点通过读取etcd获得需要执行的工作负载，该方法在数据中心已经被证明是一种安全且高效的模式。但边缘计算与云数据中心之间往往是由不稳定网络连接的，如果直接将边缘计算设备是为Kubernetes工作节点，Kubernetes会把网络通信错误是为工作节点失败，从而频繁的出现错误的工作负载迁移。
边缘计算的云原生化管理最核心的问题就是如何实现一套在不稳定网络下保证Kubernetes稳定编排的机制。综合业界不同的实现，解决编排的稳定性问题一般分为三个流派。
虚拟节点模式
虚拟节点即为每个边缘计算设备创建一个逻辑上的、虚拟的Kubernetes工作节点，称为virtual-kubelet。虚拟节点本身与Kubernetes位于同一个网络内，从而可以“接受”到稳定的工作负载编排。随后虚拟节点将自身工作负载的配置下发到真实的边缘设备上，由此实现了间接的稳定编排。
虚拟节点的缺点在于隔绝了云和边缘的实际状态，云端难以根据边缘的实际情况随时调整负载，边缘也只能被动接受编排结果。边缘计算即使拥有多个节点，在云端的Kubernetes看来也只是一个单独的虚拟节点，这就导致在本地很难实现真正的自动负载均衡和故障转移。
同步状态复制
对虚拟节点的一种改造思路是将本地边缘计算系统视为一个单独的Kubernetes集群。这种方法能够保证本地拥有足够的编排灵活性，云端只需向下同步工作负载的内容而无需关注具体的编排，其技术要点在于如何保证下发数据的一致性，也就是如何正确的同步复制etcd状态数据库的内容。
同步状态复制的缺点表现在引入了多套Kubernetes集群，需要新增数据同步协议，且etcd数据属于Kubernetes的“内部数据”，这可能带来更高的开发和管理成本。
Shadow CRD
Custom Resource Definition是Kubernetes社区推荐的功能扩展机制。通过CRD可以引入“特殊”的资源，比如一个具有自编排能力的边缘计算节点即可视为一个新的CRD资源。CRD提供了标准的编程接口，能够在不破坏Kubernetes内部封装性的前提下改变其编排行为，如服务的有序启动、服务与存储的绑定关联等等。
Device Shadow是来自物联网的概念，即每一个物理设备（Device）都有对等的影子对象（Shadow），设备在不同时期的状态对应于影子的不同版本。应用通过读取影子当前版本的数据状态就能获得设备的当前状态，通过设置一个新的影子版本就能反向控制设备改变状态，实现各种功能调整和能力升级。由于物联网设备普遍运行在不稳定的网络环境中，影子协议天然的将最终一致性作为第一优先，内置了各种针对数据丢失和数据重复的处理策略。另外，物联网底层广泛使用的MQTT协议很好的处理了低带宽和低功耗设备。综合以上两点，使用数字孪生技术可以很好的满足边云同步对一致性和网络质量的要求。
Baetyl 2.0通过将上述两项技术结合，实现了单一Kubernetes集群内的全局边缘稳定编排。在实现上，Baetyl-Cloud组件会将对资源的声明转化为对影子设备的状态期望，然后通过MQTT协议向Baetyl设备发送通知。后者影子状态解码后就能得到Kubernetes的资源定义，同时再以MQTT协议向上汇报新的影子设备状态。通过这样的方法，Baetyl就能够在弱网络条件下让云和边缘总是能正确的同步。
Shadow CRD是一种灵活、高效且不损失信息的边云同步技术，未来通过与Operator的结合会进一步提升全局自动化管理的能力。
五、总结
边缘计算在过去几年经历的极为快速的技术演进，背后是产业数字化需求的强大推动，与云原生模式的结合将能让边缘计算更好的吸收云、大数据和AI的成果，并让后者进一步扩展应用范围。
尽管边缘计算仍然处在发展的初期，但随着全球开源社区的蓬勃发展，边缘计算必然会将越来越多的创新带入各行各业，成为推动智能化时代的关键力量。
