「译文」CNCF 边缘原生应用程序原则白皮书
本文最后更新于：2024年7月24日 晚上
👉️ 原文 URL: https://www.cncf.io/wp-content/uploads/2023/03/CNCF_WhitepaperReport_23.pdf
✍️Author: The CNCF IoT Edge Working Group
📝Description:边缘原生白皮书在边缘计算环境中，计算、连接、存储和功耗都受到限制，因此需要新的方法和一组新的边缘原生原则来。…
目标
许多地方都提到了“Edge Native（边缘原生）”一词，包括 Gartner、Marcometa 和 FutureCIO 等行业博客。包括 State of the Edge 和 Linux Foundation（LF） 在内的组织也讨论了边缘原生应用程序，但没有关注边缘原生原则。
本白皮书重点介绍边缘原生应用程序以及如何定义这些原则。
什么是边缘 (Edge)?
边缘计算是一种使数据处理更接近源 (source) 的范例，例如工厂中的机器人控制。
在未来五年内，边缘计算 (Edge Computing) 将变得更加普遍，预计该行业将 从 2022 年到 2030 年增长 38.9%。公司看到了在边缘拥有计算能力的以下好处：
- 减少延迟
- 带宽管理
- 提高敏感数据的隐私性
- 在不可靠的网络下不间断地运营
边缘计算有各种各样的定义，但本文将重点讨论的是基于数据处理资源的地理位置 (the geographical location of data processing resources) 的定义。 基于地理的边缘根据与用户的距离被分类为多个类别。 下图显示了 Linux Foundation Edge 白皮书 中定义的类别。
（译者注）根据距离中央（云）数据中心由远到近依次为：
- 用户边缘 (User Edge)
- 受限的设备边缘 (Constrained Device Edge): 基于微控制器，在物理世界中高度分布式。如智能灯泡，智能温度计。
- 智能设备边缘 (Smart Device Edge): 包括 IoT（无头）和可访问位置的最终用户客户端计算设备。如：智能路由器，智能手机。
- 本地数据中心边缘 (On-Perm Data Center Edge): 安全位置中基于服务器的计算。如：放在监控室的机柜。
- 服务提供商边缘 (Service Provider Edge): 距离用户边缘相隔最后一公里网络 (Last Mile Networks)
- 访问边缘 (Access Edge): 电信网络和边缘交换站点的基于服务器的计算
- 区域边缘 (Region Edge): 区域电信公司和直接对等站点的基于服务器的计算
- 中央数据中心 (Centralized Data Centers): 通过互联网边缘 (Internet Edge) 与服务提供商边缘相连；传统云数据中心中的基于服务器的计算
边缘原生原则与云原生原则共享许多相似之处；
但是，也有一些关键的区别。
云原生 (Cloud Native) VS 边缘原生 (Edge Native)
云原生计算基金会（CNCF） 定义的云原生技术包括：
“云原生技术使组织能够在公共云、私有云和混合云等现代动态环境中构建和运行可扩展的应用程序。 容器、服务网格、微服务、不可变架构和声明式 API 就是这种方法的例证。
这些技术使松散耦合的系统具有弹性、可管理性和可观察性。
结合强大的自动化功能，它们允许工程师以最少的工作量频繁地、可预测地进行高影响力的变更。”
这一广泛的使命仍然适用于边缘应用程序，因为 边缘计算开放词汇表 (The Open Glossary of Edge Computing) 指出，“边缘原生应用程序”利用云原生原则：
“应用程序是为了利用边缘计算功能而本机构建的，这在集中式数据中心中运维是不切实际或不可取的。 边缘原生应用利用云原生原则，同时考虑到边缘在资源限制、安全性、延迟和自主性等方面的独特特征。 边缘原生应用程序的开发方式充分利用云并与上游资源协同工作。 不理解集中式云计算资源、远程管理和编排或利用 CI/CD 的边缘应用程序不是真正的“边缘原生”，而是更类似于传统的内部部署应用程序。”
随着云原生使用案例走出传统云，在边缘位置整合数据和事件，新的工具和技术也在不断发展，以实现交付具有弹性、可管理和可观察性的松耦合系统的目标，同时还能管理边缘的独特特征。
相似性
许多云原生原则适用于边缘原生。 本节将介绍这些相似之处。
| 属性 | 云原生 & 边缘原生 |
|---|---|
| 应用程序和服务可移植性 | 应用程序和服务将它们的耦合从架构中抽象出来。 一个写得很好的应用程序不能告诉它在哪里运行，可以预期它是跨平台的。 |
| 可观察性 | 该平台附带了一套记录良好的界面和工具选项，可用于检测问题和收集指标。 这使得开发人员能够构建具有弹性和高效管理的系统。 |
| 可管理性 (Manageability) | 提供了接口和工具选项来大规模管理应用和资源。 该平台还具有插件机制，可提供基线网络连接、服务和管理功能。 |
| 不可知语言和框架支持 | 应用程序和服务可以使用各种流行的语言和框架来实现和托管。 |
差异性
| 属性 | 云原生 | 边缘原生 |
|---|---|---|
| 应用模型 (App Model) | 大多数微服务组件是无状态构建的，用于负载平衡的水平扩展。 | 虽然服务提供商边缘应用程序可能非常相似，但用户边缘 (User Edge) 应用程序可能是单独的“单体 (monolithic)”; 在这两种情况下，状态都可以与应用程序位于同一位置。 |
| 数据模型 (Data Model) | 支持无状态组件的集中式模型很常见。 | 通常使用缓存 (caching)、流 (streaming)、实时 (real-time) 和分布式模型。 |
| 弹性 | 快速扩容和缩容；通常将底层资源视为无限的。 | 由于边缘硬件资源有限，弹性有限；如果可用，扩展可能是“垂直”的，直扩展到连接的云。 |
| 恢复能力 (Resilience) | 使用跨故障域分布的冗余节点将恢复能力外包给云提供商。 | 通常依赖于加固的架构，以及用于有状态组件的恢复体系架构；在许多情况下，恢复能力可能低于云中的恢复能力。 |
| 扩展 (Scale) | 通常仅限于几个地点和实例。 | 可跨越大量位置（多达 10，000 个），支持大量外部设备（多达 100，000 个）。 |
| 编排 | 大型公有云或内部部署云中的流程编排旨在通过在集中池化主机上运行工作负载并以水平方式进行调度来实现效率和可用性。 | 边缘是分散式的，工作负载以分布式方式部署，通常以特定于位置的方式进行调度。 |
| 管理 | 虽然云原生和边缘原生都是可管理的，但机制各不相同；云原生依赖于集中管理和自动化。 | Edge 原生需要远程和集中化管理以及零接触配置硬件和软件。 边缘工作人员可能未经培训、不受信任、人数极少，甚至根本不存在。 “板砖”标准化，“原子”化升级由于恢复挑战而变得合乎需要。 |
| 网络 | 应用程序可以依赖具有丰富功能的高速网络。 | 应用程序需要考虑不同的速度（从间歇性的、差的到优秀的网络）和功能。 包括基于移动网络和无线电网络，集成来自非 IP 协议网络的数据和事件。 |
| 安全 | 安全设施内的可信结构。 | 不安全环境中的零信任。 |
| 硬件感知 | 由于计算资源事实上是一致的，并且具有迎合大多数应用的风格，因此应用很少需要关心硬件放置。 | 应用程序可能具有更高的实时要求，这使得硬件平台、位置和 / 或安全感知成为一项要求。 开发人员需要了解各种各样的硬件和接口。 |
| 与外部资源交互 | 应用程序很少需要与本地硬件资源交互。 | 部署在边缘的服务通常需要与本地环境交互：摄像头、传感器、执行器、用户等。 |
边缘原生应用
边缘原生应用程序是为边缘编写的应用程序和服务。 它们的编写方式考虑到了上述的相似性和差异性。 这些应用程序的核心原则如下所示：
| 原则 | 描述 | |
|---|---|---|
| 资源和设备感知 | 硬件感知 | 开发人员需要了解各种各样的硬件和接口，而不是拥有同质的硬件平台。 |
| 外部设备连接 | 应用程序必须知道如何连接到其环境中的设备，并了解运行时的功能更改。 例如，在初始配置或新设备进入网络后，它们必须响应传感器与边缘服务器的断开 / 连接。 能力不是一成不变的；相反，它包括环境，所以编排器应该能够协调应用程序状态的能力变化。 | |
| 可变网络可用性感知 | 应用程序必须通过使用异步通信、队列和缓存等机制来适应不可靠甚至不可用（网络隔离）的网络连接。 边缘从中央站点拉取配置时，可能需要“拉取 (pull)”机制来克服规模、网络连接和安全问题。 |
|
| 大规模管理 | 中心可观测 | 虽然边缘和云原生应用都需要集中观察，但边缘原生应用有独特的考虑因素。 边缘原生应用实例可能部署在大规模实例中，并且 / 或者面临人员或现场支持受限的情况。 由于这些原因，需要诸如分布式数据收集和集中式聚合、开环 (open loop)（人类可观察 / 可操作）和闭环自动化（机器可操作）的组合等技术。 可观察性包括指标、日志、数字孪生、警报 (alerting)（事件 (events) 和警报 (alarms)）和运行状况监控。 |
| 大规模架构和平台管理 | 大规模的架构和平台管理对于边缘应用程序非常重要，因此需要基于声明性意图的机制。 此外，可能存在独特的要求，如设备加载、水平扩展限制、管理裸机环境等。 在平台级别，部署或管理 Kubernetes 或虚拟化层以及各种插件也是一个问题；同时尽可能保持平台层与厂商无关以实现应用程序的可移植性。 | |
| 大规模应用管理 | 边缘应用程序的数量和这些应用程序的实例数量可能非常大，需要从声明性放置和配置意图、通过闭环自动化实现的自动化服务保证，以及跨多个应用程序实例的聚合管理视图等一系列自动化。 应用程序也可能有实时需求，这意味着应用程序和架构 / 平台之间的联系（例如使用 GPU、DPU、FPGA、CPU 架构、内核优化、Kubernetes 插件）可能比云应用程序更紧密。 换句话说，应用程序协调可以触发底层的架构 / 平台协调。 | |
| 扩展 (Spanning) | 应用程序不存在于一个位置；层可以跨越地理、延迟和故障域边界。 事实上，边缘应用程序也可以跨越公共云或集中式私有云。 | |
| 资源使用优化 | 由于边缘计算资源有限，应用程序必须持续优化资源使用。这可能意味着按需启动和关闭应用程序，可能意味着根据放置和可用性意图进行迁移和复制，可能意味着在一天中的不同时间运行不同的工作负载。 | |
| 应用程序可移植且可重复使用（有限制） | 抽象层试图通过厂商中立的 PaaS 提供架构和平台无关的可移植性。 但是，由于本地资源、硬件平台、安全性、移动网络等认知，需要配置选项适应本地差异。 |
这九项原则可以归纳为五大项原则。 硬件感知、外部设备连接和可变网络可用性感知都可以在资源和设备感知的更广泛原则下考虑。 类似地，边缘应用程序需要可大规模管理、可集中观察。 并且具有可管理的架构和平台，都可以在大规模管理的原则下进行分类。 以下是扩大后的五项原则：扩展、资源使用优化、可移植性和可重复使用性（有限制）、资源和设备感知以及大规模管理。
总结和下一步
本文件是第一版，可能会经过修订。 预计今后将发表与本文件各小节有关的文章。
如何参与
CNCF 物联网边缘工作组有定期会议、邮件列表和 Slack。 请参阅工作组 GitHub 页面的 通信部分 以获取最新信息。
我们欢迎读者参与进来，介绍与边缘相关的项目，为小组的工作领域提出想法，或帮助修改本白皮书和 / 或起草后续文件。
项目和举措
作为本白皮书的一部分，CNCF 物联网边缘工作组正在收集开源项目的工作列表，这些项目可帮助应用开发人员实现本文中概述的边缘原生应用原则。
该列表可在此电子表格中或通过 QR 码找到。 要获得添加项目的编辑权限，请加入 IoT Edge Working Group Google 群组。
引用
- Linux 基金会边缘白皮书：https://www.lfedge.org/wp-content/uploads/2020/07/LFedge_Whitepaper.pdf
- 开放式边缘计算词汇表 [v2.1.O] 边缘状态：https://github.com/State-of-the-Edge/glossary/blob/master/edge-glossary.md#edge-native-application
- CNCF Charter: https://github.com/cncf/foundation/blob/main/charter.md
- Gartner ‘云原生不是边缘原生’: https://blogs.gartner.com/thomas_bittman/2020/04/17/cloud-native-isnt-edge-native/
- Macronmeta ‘边缘原生不是云原生’: https://www.macrometa.com/blog/edge-native-is-not-cloud-native
- Future CIO ‘云原生 vs 边缘原生：了解不同’: https://futurecio.tech/cloud-native-versus-edge-native-know-the-difference/
- 边缘计算市场规模、份额和趋势分析报告（按硬件、软件、服务、边缘管理平台）、按应用程序、按垂直行业、按地区和细分市场 2022 - 2030 年预测：https://www.grandviewresearch.com/industry-analysis/edge-computing-market
'