“边缘云原生”是云原生社区最近几年一个新的发展方向。它试图将边缘计算的应用场景也纳入到现有云原生技术体系中。这篇文章将讨论为什么会出现“边缘云原生”这样的技术方案，边缘计算的场景会给传统云原生技术带来哪些挑战，以及现在的边缘云原生方案是如何应对这些挑战的。 以下都是纸上谈兵的一家之言，贻笑大方还请各位批评指教。
“云原生”时代的到来
互联网行业向来有喜欢造词的传统。只要你在这个圈子里，各式各样的buzz word总会不断跳入你的视线里。而近年来涌现出的一批新词，包括：容器化，微服务，持续集成持续交付，DevOps, Service Mesh等等这些其实都可以统一到“云原生”这一大框架中来。在介绍什么是云原生之前，我想先聊聊软件设计结构的演进过程。
传统的软件开发基本上都是以单体应用的形态出现的。所谓单体应用，顾名思义就是把所有的业务逻辑都塞到一个大的应用中去。就像我们在学校里做过的课程项目，我们会有一个庞大的后端，也许会用上SpringBoot这样的框架，遵循MVC范式来进行开发。当然这个应用也会有模块设计与业务拆分，但是这些模块基本上都是强耦合在一起而不能独立存在的。单体式应用的优势在于结构简洁，易于开发，因为各个模块都在同一个应用之中，可以直接交互。但是随着互联网需求的爆发，单体应用的代码库会越来越臃肿，难以维护，扩展性差。
当部署在单台机器上的单体应用难以承载日益增长的用户访问需求时，我们需要将这个庞大的系统进行拆分，将其分割成不同的业务模块，部署到多台的机器上，各个模块通过事先约定的接口进行网络通信（比如RPC）。这也就是所谓的分布式架构。也许我们还可以更进一步，考虑使用分布式数据库（比如TiDB）代替传统的数据库来满足扩展性的需求。当然在这样一个分布式系统中，通常我们还需要通过一个反向代理服务器Nginx代理转发用户请求，完成负载均衡的任务。分布式架构提升了整个系统的负载能力，解决了高并发的需求，但是也同时带来了一系列的问题。首先，分布式本身的复杂性增加了开发和运维的成本，比如这样一个系统我们需要考虑系统可靠性，一致性等问题。另外，用网络请求代替本地函数调用让模块间的通信成本上升。
Docker为代表的容器技术诞生，将物理机器级别的分布式提升到容器级别的分布式水平。容器技术广受推崇因为它解决了物理级别分布式的许多潜在问题。比如，如果我们将多个模块（或叫服务）部署到一台机器上，这些服务都将会以一个个进程的形式共享这一台机器的资源。那首先会存在进程间资源竞争的问题，假如某个服务的进程占用大量机器资源，不可避免地影响其他进程的运行，从而拖累整个系统的表现。其次，多个服务的进程可能还会带来潜在的安全问题。容器技术让各个服务运行在抽象的容器中，共享同一台物理机的资源的同时相互隔离，互不干扰。而且相比于传统的虚拟机技术它性能损失小，启动快。微服务架构把一组服务以容器的形式部署到一个集群中。
微服务架构催生出了管理一个集群中大量容器的需求。2014年发布的Kubernets（也叫K8s）在这个领域脱颖而出，已经形成了一个繁荣的社区生态。它能帮助监控容器运行状态自动重启，管理容器间的网络通信进行网络代理，自动伸缩动态调度资源。K8s这种声明式配置和自动化管理，减轻了微服务带来的运维压力。
如果我们从一个整体的视角看待整个架构变迁发展的过程，可以看到一个明显的趋势是，应用与“云”的结合越来越紧密。从传统的与“云”完全无关的单体应用，到把使用云上的基础设施（比如把应用部署到云服务器），到使用云上的服务（比如使用云数据库），到整个基于云开发的微服务架构。这实际上就是“云原生”概念提出的时代背景。
云原生是指从云的原生应用角度出发，一整套设计、开发、部署、运行、维护的流程、技术栈以及背后文化理念的统称。
云原生希望建立一套围绕着云进行软件开发的标准化、系统化的流程方案。云原生应用天然具备弹性扩展，快速迭代交付，开发成本低等优势，另外云带来的运维成本正在被云原生社区活跃的新架构新方案（如Service Mesh）逐步解决。在云原生的愿景中，开发与运维将会完全解耦，最终开发者只需要关注业务开发而不是把开发和运维搅在一起。
云原生 + 边缘计算 = 边缘云原生
边缘计算一定程度上是一个与云计算相对的概念，它指的是一些需要发生在网络边缘的计算场景。计算发生在边缘可能有多方考量，比如有些涉及图像视频处理的场景可能囿于网络带宽成本希望在网络边缘设备上处理，比如自动驾驶中一些需要及时得到结果的计算一定要在本地完成，再比如一些涉及隐私的数据（人脸，人声）用户希望不要上传到云端。总之，随着万物互联时代的到来，边缘计算的需求将会越来越强烈。
这里有一个虚构的简单边缘计算案例。比如我们有一个人脸识别的边缘计算需求，我们希望借助数据中心的算力来训练一个人脸识别的AI模型，同时将训练好的模型部署到边缘设备上完成及时的预测。整个流程可能要经历这样四个阶段，首先在云端训练好模型，然后把模型分发部署到边缘节点，之后边缘节点用这个模型来进行预测并且把预测结果上报回云端，接着云端利用这些数据再进行模型迭代。至此构成了一个应用闭环。
从这样一个简单的案例，我们能看出在如今云时代下边缘计算的一些特点。
- 云-边双向通信。云计算与边缘计算不是割裂的而是需要有交互的，边缘是云的延伸。在我们例子中，云需要向边缘分发部署模型，边缘需要向云上报模型预测结果。即使计算资源和设备可能在边缘，但是我们希望这些资源的注册上报是由云端来统一管理的，另外计算应用也是由云端统一部署的。
- 云-边松耦合。即边缘节点需要不依赖于云端（甚至在断网环境）可靠地完成本地任务，也就是所谓的边缘自治。另外，可能还需要边缘节点之间能够不通过云端，局部互相感知通信。
- 边缘计算自身的一些特性。设备分散海量，网络条件复杂，计算资源有限，设备异构。
让我们从云原生的视角审视上述边缘计算的特点，其实很多问题是现有云原生技术已经解决的问题。比如大量设备的统一交付，运维，部署，只不过之前的节点还在云上，现在需要部署到网络边缘。再比如我们仍然可以借助轻量化的容器化技术管理大量的异构计算资源。再加上，云原生社区本身的繁荣和统一的标准，K8s也适合用于扩展和二次开发。所以借助云原生现有技术，解决边缘计算场景问题，实现“云-边一体化”的边缘云原生，也就理所当然成为了下一个热点问题。
边缘云原生面临的问题
虽然云原生技术自身的优势使其已经能够解决边缘计算场景里的一些问题，但是直接将云上的技术下放到边缘还是难免有些水土不服。接下来我们看看边缘云原生会遇到哪些问题？
在介绍这些问题之前，首先我们要对云原生社区中的核心技术——K8s有一定的了解。K8s被称为云时代的操作系统，它已经成为云原生领域事实上的标准。与其说它是一个管理容器的工具，它更像是一个可定制可拓展的平台，已经形成了繁荣的生态。很多边缘云原生技术方案都是基于K8s进行二次开发完成的。我们这里简单的介绍一下K8s的功能和特点。
K8s使用Master-Slave架构来管理集群。
Master：
- etcd: 集群信息数据库，以key-value形式持久化保存集群所有数据信息。
- API Server：Kubernetes与外界交互的门户，同时也是Node节点与Master节点交互的门户。它将K8s所有的功能以REST API的形式暴露出来。为了防止请求压力过载，一个集群中可以部署多个API Server实例。
- Scheduller: 根据软硬件环境，调度集群节点上的容器资源。
- Controller: 监控节点状态，管理节点任务。
Node：
- Network Proxy: 代理节点的网络通信。
- Kubelet： 管理节点上所有K8s集群中的容器。
- Container Runtime：严格来说不属于K8s，但是K8s需要Node上有一个符合K8s CRI接口标准的容器运行时来运行容器。
通过这些组件，K8s可以管理容器集群的工作负载和服务。但是由于它最初是为部署在数据中心的集群设计的，而这种对集群运行环境的假定和预设不适合边缘计算的环境。也就是说如果我们直接把K8s扩展到边缘计算场景中，会遇到一些问题，这体现在以下几个方面：
- 边缘离线自治能力的缺失。如果我们直接把Node部署到边缘，那么在一些场景中，Node节点失去与Master的联系后不能正常工作。
- 边缘网络环境的不确定性。数据中心中的网络一般都是稳定连通的，但是边缘计算场景中网络环境可能较为复杂。比如K8s中的List-Watch异步消息处理机制，这种全量获取，增量更新的方式在网络频繁断接的情况下会带来较大的网络负载压力。
- 边缘计算资源的有限性。在一些特殊场景中，很难保证边缘节点上的资源可以同时满足K8s Node各个组件以及计算应用的需求。
一个边缘云原生解决方案实例
针对这些问题，现有的基于K8s的边缘云原生解决方案都给出了各自的解法。比如轻量化K8s使可以将集群独立部署在边缘的K3S，对Kubelet进行精简改造的KubeEdge，主打“非侵入式云边一体化”的OpenYurt。
下面以腾讯开源的SuperEdge为例介绍一下它如何应对这些问题。
SuperEdge是一个腾讯开源的边缘云原生解决方案。它和OpenYurt一样基于K8s现有功能以一种无侵入式的方式进行二次开发（直接以go mod形式引入K8s），可以说是一个标准的K8s“套壳”应用。这样带来的优势是减轻了后续与K8s同步升级的维护压力。它在K8s的基础上扩展出了下面👇几个功能：
- 边缘自治，使边缘节点不依赖于与Master的联系，可以自主运行。
- 复杂网络下的云边协同，即使边缘节点部署在局域网内没有公网IP，也能实现云边双向通信
- 边缘节点分布式健康检查，边缘节点的状态不仅由其与Master的连接确定，而且由与其一组的边缘节点组内连接共同确定。
- Service Group服务级别的控制粒度
大体来说，SuperEdge通过在边缘侧添加一层代理服务来缓存请求的方式让Node端在断网情况下也可以正常运行。另外，它使用gRPC中bidirectional streaming解决了边缘测无公网IP情况下的双向通信问题。而且通过边缘测分布式健康检查可以保证在弱网条件下workload的正常运行。ServiceGroup可以便捷地在共属同一个集群的不同机房或区域中各自部署一组服务，并且使得各个服务间的请求在本机房或本地域内部即可完成，避免服务跨地域访问。
总结
- “云原生” 正在成为IT领域的新范式，它对软件行业的影响将体现在从软件开发流程到软件体系架构设计等方方面面。
- 边缘计算场景对传统“云原生”技术提出了新的要求，比如云边协同，边缘自治，复杂网络环境下通信等。
- KubeEdge, OpenYurt, SuperEdge等一批基于k8s的云原生社区开源解决方案，扩展了传统“云原生”的能力，使其能够服务边缘计算场景。
