作者：良名
云原生与边缘
随着云技术的发展与普及，以 K8s 为代表的云原生概念越来越被企业所接受，成为企业数字化转型的坚实基础。其所倡导的不可变基础设施，以资源为管理对象，描述性的 API，最终一致性等等理念，已经成为行业对基础设施的统一认知标准。
边缘计算并不是一个全新的概念，而是很早就被提出并且在不同的时代都有很多实现的一种架构模式。旨在将算力尽量推进到数据产生的源头，以避免由于网络或者是其他硬件条件限制带来的系统不稳定，提升系统终端的响应速度。
传统的边缘计算产品，更加侧重边缘侧的通信能力。但是在云原生场景下，如何既能享受云原生带来的各种特性和优势，又能避免边缘场景天然的限制和约束，是今天云边协同边缘平台亟待解决的问题。
CNStack 云边协同平台 - EdgePaaS 专注于在云原生的技术栈下实现边缘计算能力。下面分别通过：资源协同、应用协同、服务协同、数据协同、设备协同 5 大协同能力介绍 EdgePaaS 的产品特色，以及 EdgePaaS 是如何助力业务落地边缘。
产品特点
资源协同
K8s，站点
云边协同平台的设计宗旨，是在 K8s 的基础上，尽量减少对用户的侵入，仅通过少量概念实现云边之间的资源管理协同。
云边协同平台提出“站点”的概念，实现边缘资源的统一管理。
站点，有点类似于可用区的概念。如果仅从资源分组的角度看，确实有相似之处。但是，这两者有着本质的区别。可用区是从可用性的角度对资源进行的划分方式，其核心目标是实现业务容灾。但是，“站点”通常是基于地理因素或者是业务上的管理关系对资源进行的划分，其本质依然是边缘自身的业务管理规则的投射。
通过“站点”，计算、网络、存储等基础设施资源，都可以在站点维度独立维护，每个站点甚至可以看做是一个独立的小集群。
应用协同
应用定义、分发、部署、运维，断网自治
即使在云边协同架构下，“应用”依然是第一公民。
应用是数字世界，对各种业务工作负载的统一抽象。即使是在边缘场景，无论有多么丰富的设备，产生了多少各式各样的数据，核心的业务逻辑还是在"应用"中，我们需要"应用"来处理和分析这些数据，然后再触发下游逻辑。
EdgePaaS 不会对业务应用做任何的特殊要求，只要是标准的 K8s 应用都无需任何修改，无论是直接采用工作负载的封装方式，还是采用 Helm chart 的封装方式，都可以直接使用，并获得边缘环境下的管理、分发、部署、运维、监控等全生命周期的操作能力。
在 K8s 之下，如果一个节点的网络发生了终端，平台将会把这个节点驱逐并将节点上工作负载漂移至其他可达的节点。这一特性在 K8s 框架下可以大幅提升业务应用的可用性，但是由于边缘场景下网络天然的脆弱性，这一特性反倒会带来边缘应用极大的不稳定。EdgePaaS 针对这一问题，实现了一套边缘自治机制。
边缘站点发生了网络中断以后，中心管控会暂定对边缘节点的调度，但是不会驱逐已经存在的业务负载，而是等待边缘节点的网络恢复。在边缘侧，管控程序也不会因为和中心侧断联而将本节点内的负载停止，而是持续尝试连接中心，直到网络恢复。
服务协同
服务拓扑
在传统的中心化架构下，我们通过注册中心实现服务间的发现，依托于服务集群的网络联通性实现服务间的通信。但是在边缘环境下部署的应用，每个站点内的服务都是独立的实例，几乎不存在站点之间的调用，所有的服务都应该发生在站点内部以及或者是云边之间。
EdgePaaS 可以让一个服务根据集群的节点的分布进行流量路由。例如，一个服务可以指定流量被优先路由到和客户端 pod 相同的节点或者节点池上。
数据协同
流量优化、内容分发
由于边缘环境天然的特殊性，带来了网络上的各种限制，主要包括：
- 云边网络带宽受限
- 云边流量成本高
- 网络单向可见
- 网络可靠性差
由于这些这些限制条件的出现，云边数据协同将不再简单。针对边缘网络的特殊性，EdgePaaS 分别对运维数据和业务数据做了不同的协同支持。
运维数据协同
管控数据，在云边之间的通信存在很大的重复性，尤其是在 K8s 之下，各种组件的运行都依赖于大量系统资源，例如：node、pod、endpoint 等。这一类数据的流量会随着站点内节点数的增加而显著上升。
在一个站点维度，站带内部的网络环境是相对宽松的，EdgePaaS 在每个站点开启一个中心侧 apiserver 的代理，将站点内被重复获取的网络资源统一代理，使得边缘侧管控流量不会随着节点数的增加而增加。
业务数据协同
在云边之间流转的，除了运维数据，还存在着大量的业务数据。例如一张图片、一个算法模型、一个镜像等。这些内容具备如下显著的特征：
- 内容不可变
- 在中心侧管理，边缘侧使用
- 内容需求对带宽要求大（可以是单个大文件，也可能是多次需求的小文件）
- 对响应速度有要求
针对这种场景，EdgePaaS 提供了一套完整无侵入的解决方案：
在边缘站点侧，EdgePaaS 提供站点维度的访问代理，数据消费者只需要使用标准协议（http、ftp、sftp）即可获取关注的数据。同时依托于服务协同中就近访问的特性，用户无需为每个站点的应用做单独的配置，全部共享一个服务即可实现内容的获取。
使用这套方案，对静态资源的访问流量将会显著下降，有效降低对云边带宽的要求，同时还能在网络中断场景下持续提供资源访问能力，进而进一步为断网自治能力保驾护航。
同时，此方案还具备预热的能力。由于内容分发的流程是独立于数据消费流程的，所以可以在消费行为发生之前，提前将消费者需要使用的数据主动对送到业务单元，进而实现数据预热。
设备协同
设备孪生
EdgeX Foundry 是一款由社区提供支持的边缘物联网即插即用型、开放式软件平台。它具有高度灵活和可扩展性，可以大大降低应用与边缘设备，传感器等硬件互操作的复杂性。EdgeX Foundy 采用分层和服务的设计，从下至上分别是设备服务，核心服务，支持服务，应用服务以及安全和管理两个辅助服务。EdgeX Foundry 的分层和服务为边缘设备/节点和云/企业应用之间提供了一个双向转换引擎。可以将传感器和节点数据按特定格式传输到应用，也可以将应用指令下发到边缘设备。
EdgePaaS 通过 OpenYurt 集成 EdgeX 框架，将完整生设备态落地到边缘站点。用户可以一键在边缘站点部署 EdgeX 套件，还支持通过操作 CR 的方式来访问、管理、操作IOT设备，以此实现设备孪生能力。同时，在设备协议支持方面，EdgePaaS 内置了多种常见的设备协议驱动：ModBus、MQTT、ONVIF、GPIO、REST等。
在云边场景下使用设备孪生的能力，还会带来如下优势：
- 降低设备连接的复杂度
- 提升系统响应速度
- 隔离设备设备开发和应用开发，提升集成能力
