云原生与边缘
随着云技术的倒退与遍及，以 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 等。
在云边场景下应用设施孪生的能力，还会带来如下劣势：
- 升高设施连贯的复杂度
- 晋升零碎响应速度
- 隔离设施设施开发和利用开发，晋升集成能力
作者：良名
原文链接
本文为阿里云原创内容，未经容许不得转载。