边缘计算

边缘计算：架构、设计和测试的下一步

简介

虽然边缘计算在过去几年中迅速普及，但相关术语的定义以及满足这种新型应用部署方式不断涌现的使用场景所需的正确商业模式、架构和技术仍然存在无数争论。

在我们的 之前的白皮书 中，OSF 边缘计算小组将云边缘计算定义为通过将传统数据中心的 capabilities 扩展到边缘，向最终用户交付资源和功能，无论是通过将每个独立的边缘节点直接连接回中央云或几个区域数据中心，还是在某些情况下相互连接成网状结构。从鸟瞰的角度来看，大多数这些边缘解决方案看起来松散地像大小和复杂性各异的互连蜘蛛网。

在这些类型的基础设施中，没有明确定义的边缘；大多数这些环境都是有机增长的，并且各种组件可能由不同的组织拥有。例如，公共云提供商可能提供一些核心基础设施，而其他供应商提供硬件，还有第三组集成商构建软件组件。由于各个行业细分市场的应用需求各不相同，因此尝试为边缘用例创建一刀切的解决方案是不可能的。有趣的是，虽然云转型在电信行业起步较晚，但运营商一直是云计算演进到边缘的先驱。作为网络的拥有者，电信基础设施是边缘架构的关键底层要素。

四年后，虽然毫无疑问边缘计算仍然受到关注，但对于标准的边缘定义、解决方案或架构仍然缺乏共识。但这并不意味着边缘计算已经死亡。边缘计算本质上必须具有高度适应性。适应性对于将现有软件组件演进到新环境或赋予它们更高的功能至关重要。边缘计算是一种技术演进，它不局限于任何特定行业。随着边缘计算的演进，越来越多的行业发现它具有相关性，这只会带来新的需求或改变现有需求的背景，吸引新的参与者来解决这些挑战。现在比以往任何时候都更需要对边缘计算拥有光明的前景！

本文档重点介绍了 OSF 边缘计算小组的工作，以更精确地定义和测试各种边缘参考架构的有效性。为了帮助理解挑战，其中包含来自各种行业细分市场的用例，展示了如何使用参考架构模型来满足这些需求，从而实现部署和分发云资源的新范例。

不同行业面临的挑战

简而言之，边缘计算通过增加端点数量并将它们定位在更靠近消费者（无论是用户还是设备）的位置，将更多的计算能力和资源转移到更靠近最终用户的位置。从根本上说，边缘计算架构建立在现有的技术和分布式系统的既定范例之上，这意味着有许多众所周知的组件可用于创建最有效的架构来构建和交付边缘用例。

本节将引导您了解一些用例，以展示边缘计算如何应用于不同行业并突出其带来的好处。我们还将探讨一些差异化需求以及架构化系统的方式，以便它们不需要仅仅为了符合要求而进行彻底的基础设施改造。

5G 带给你边缘计算，还是反过来？

5G 电信网络承诺极高的移动带宽，但为了实现这一目标，它们需要大规模的新型和改进的 backbone 基础设施来管理复杂性，包括关键流量优先级排序。网络需要提供高吞吐量和低延迟，并结合高效利用可用容量，以支持新兴 5G 服务的性能需求。

诸如 IMS 控制平面或分组核心之类的信号功能现在依赖于大型集中式数据中心中的云架构，以提高灵活性并更有效地利用硬件资源。但是，为了在用户平面和无线应用中获得相同的优势，而不会受到光速物理限制的阻碍，计算能力需要进一步扩展到网络的边缘。这使其能够提供无线设备和应用之间所需的高带宽，或满足低延迟的需求。

最常见的方法是选择分层架构，从中央到区域再到 聚合边缘，或进一步扩展到 接入边缘层。确切的层数将取决于运营商网络的规模。中央位置通常配备完善的设备，可以处理大量的集中式信号，并针对控制网络本身的工作负载进行优化。有关信号工作负载的更多信息，请参阅 CNTT 参考模型第 2.1 章 下的控制平面，以获取示例列表。为了提高端到端效率，重要的是要注意信号处理和用户内容传输之间的分离。最终用户与数据和信号处理系统越接近，处理低延迟和高带宽流量的工作流程将越优化。

为了描述这一切在实践中的含义，以无线接入网络 (RAN) 为例。边缘架构需要重新思考基带单元 (BBU) 组件的设计。该元件通常位于无线电塔站点附近，并具有计算和存储能力。在针对边缘云的 5G 架构中，采用云 RAN (C-RAN) 方法，可以将 BBU 分解为中央单元 (CU)、分布式单元 (DU) 和远程无线电单元 (RRU)，其中 DU 功能通常在靠近用户的虚拟化 (vDU) 中实现，并结合硬件卸载解决方案，以便更有效地处理流量。上述边缘架构的说明展示了 CU 组件如何位于聚合或区域边缘站点，而 vDU 将位于边缘数据中心。这种设置允许更灵活地管理 CU 和 DU，同时保持最佳的带宽利用率，满足不断增长的用户需求。

这些架构变化为构建模块的生命周期引入了新的挑战

• 自动化：管理数十、数百甚至数千个边缘节点
• 远程配置：允许通过 WAN 连接配置远程站点的云基础设施
• “统一面板”：一个中央仪表板，用于监控边缘站点的状态，包括警报和指标
• 远程升级：边缘站点通过兼容整个基础设施的不同软件版本进行远程升级
• 弹性：在数据中心之间网络连接中断等事件发生时，能够不间断地运行工作负载

边缘计算中的内容缓存

减少回程和延迟指标以及提高服务质量 (QoS) 是将内容缓存和管理推送到网络边缘的好理由。缓存系统可以像基本的反向代理一样简单，也可以像整个软件堆栈一样复杂，它不仅缓存内容，还提供其他功能，例如基于用户设备 (UE) 配置文件、位置和可用带宽的视频转码。

内容分发网络 (CDN) 并不是一个新概念。然而，创建更多具有区域存在点 (PoP) 的 CDN 节点是现在可以被认为是近边缘计算的第一个例子之一。随着视频流、在线游戏和社交媒体的爆炸式增长，以及 5G 移动网络的推出，将缓存推送到远边缘的需求急剧增加。 “最后一英里”必须变得越来越短，才能满足客户对这些对网络延迟高度敏感的应用程序的更好性能和用户体验的需求。这正在鼓励内容提供商从传统的区域 PoP CDN 模型迁移到基于边缘的智能和透明缓存架构。

帕累托原则，或 80-20 法则，适用于视频流；也就是说，80% 的客户只会消费 20% 的可用内容。因此，通过仅缓存 20% 的内容，服务提供商将有 80% 的流量从边缘数据中心拉取。这大大降低了骨干网络上的负载，同时提高了用户体验。

边缘环境中的缓存系统需要将最终用户设备 (EUD) 邻近度、系统负载和附加指标作为确定哪个边缘数据中心将向哪些端点交付有效负载的因素。在最近的原型中，智能缓存框架使用中央云中的代理，使用基于 UE 位置和给定边缘站点负载等指标的算法将内容请求重定向到最佳边缘数据中心。

数字化时代的制造业

工业 4.0 通常被认为是第四次工业革命。该概念是工厂以新的方式使用计算机和自动化，通过结合自主系统和机器学习来制造更智能的工厂。这种范式转变包括在解决方案中使用开放的硬件和软件组件。

工厂正在使用更多的自动化并利用云技术来实现灵活性、可靠性和稳健性，这也允许引入新的方法，例如机器视觉和学习来提高生产效率。支持这些技术所需的处理数据量和计算能力正在呈指数级增长。许多应用程序将数据从工厂车间移动到公共或私有云，但在许多情况下，延迟影响和传输成本会导致装配线中断。为了满足高性能和低延迟通信需求，至少部分数据处理和过滤需要在工厂网络内保留，同时仍然能够更有效地利用云资源。由各种传感器收集的数据的进一步处理在集中式云数据中心完成。位于边缘节点的可重用便携式微服务完成新视觉应用程序或深度学习机制的一部分任务。

与电信行业类似，制造业也具有非常严格的要求。为了满足控制系统的实时和功能安全需求，它们可以使用诸如 时敏网络 (TSN) 在架构的较低层上使用的技术。

面向智能水产养殖的边缘计算

水产养殖类似于农业，只不过它不是饲养家畜，而是繁殖和收获生活在各种盐水或淡水环境中的鱼类、贝类、藻类和其他生物。这些环境可能非常脆弱；因此，需要高精度来创造和维持健康和平衡的生态系统。为了提高产量，同时为动物提供安全和健康的环境，自动化是理想的。这个用例也是设备部署和运行在恶劣环境条件下的一个很好的例子。

本节描述了虾农场，这是一个受控生态系统，人类和自动化工具监督动物从幼虫期到完全成熟的可收获阶段的整个生命周期。该系统甚至跟踪虾收获后的运输。与农业一样，环境条件会严重影响动物的状况，因此需要密切监测池塘的任何可能影响虾福祉的变化，以便及时采取行动以避免损失。

下图显示了边缘数据中心的架构图，其中使用自动化系统来操作虾农场。

需要考虑的一些系统功能和要素包括

• 环境监测，包括收集和报告诸如：室外温度和湿度、水质、PH 值和温度、溶解氧、氨、氮和亚硝酸盐等指标
• 视频监控，用于非法入侵检测和识别员工是否穿着和面部识别的合规性
• 智能育种，包括自动化喂养和库存跟踪（食物、药品、辅助材料、消毒剂等）
• 平台可追溯性，用于查询和显示整个供应链，以确保水产品的高质量

通过自动化和连接这些农场，该解决方案最大限度地减少了该行业中存在的孤立性。该平台提供数据，以便在农场本地和集中式地进行收集和分析，以改善环境条件，并在使用辅助材料和消毒剂等化学品时防止错误。

随着边缘数据中心拥有更强大的计算能力，可以存储和分析本地监控数据，以便更快地响应环境变化或修改饲养策略。该系统还可以在将数据发送到中央云进行进一步处理之前，对数据进行预过滤。例如，该系统可以预处理来自监控传感器的水质数据，并将结构化信息发送回中央云。与在中央云中执行所有操作并将指令发送回边缘数据中心相比，本地节点可以提供更快的反馈。

数字化已经带来了许多创新，但仍有改进空间，例如减少与数据收集相关的劳动力成本，并提高数据分析的速度和可靠性。借助边缘计算技术，可以构建智能水产养殖基础设施，从而引入人工智能和机器学习技术，优化饲养策略或通过最大限度地减少人为错误和更快地响应机器故障来降低成本。

技术考量

正如从这些用例中看到的，边缘和混合环境中都存在共同的挑战和功能，这些功能变得更加关键。随着用例演变为更多的生产部署，最初在“云边缘计算：超越数据中心”白皮书中记录的共同特征和挑战仍然相关。

最高的重点仍然是减少延迟和缓解带宽限制。不同用例之间的另一个相似之处，无论它们所属的行业如何，是对边缘机器学习和视频转码等功能的需求增加。由于这些应用程序和虚拟网络功能 (VNF) 等工作负载的吞吐量需求，正在利用各种卸载和加速技术来通过软件和硬件提高性能，例如

• 单根输入/输出虚拟化 (SR-IOV)：该技术允许虚拟机和容器共享对设备（如网络适配器）的不同部分的直接访问，使用 PCI Express 接口。
• 数据平面开发工具包 (DPDK)：DPDK 通过使用卸载和调度技术，允许更高的网络数据包吞吐量。虽然这不是特定于边缘的技术，但对于在高度资源受限的环境中满足严格要求至关重要。
• 非统一内存访问 (NUMA)：这是另一种通过为实例分配专用内存块来提高吞吐量的方法。为了进一步优化，内存块位于实例正在工作的 CPU 核心本地。对于非常小的边缘站点，这可能会成为瓶颈，具体取决于边缘站点的负载组合。
• 智能网卡/现场可编程门阵列 (FPGA)：这是一种硬件加速选项，已被用于 vRAN 部署，以提高具有计算密集型工作负载的站点的性能。FPGA 单元使用特定于工作负载的软件进行编程，以卸载某些特定于应用程序的算法的执行。
• 图形处理单元 (GPU)：GPU 具有大量的核心，可用于各种并行处理密集型工作负载，例如 MapReduce、机器学习 (ML)、物联网和游戏。虽然使用 GPU 是在工作负载需要时提高系统性能的好方法，但它引入了成本限制的问题，尤其是在边缘站点数量开始增加时。

参考架构

架构设计始终针对用例而定，考虑到给定计划工作负载的所有需求，并根据需要微调基础设施。如前所述，没有一种单一的解决方案可以满足所有需求。但是，有一些常见的模型描述了高级布局，这些布局对于第二天操作和系统的整体行为非常重要。

在详细介绍各个站点类型配置之前，需要决定在哪里定位不同的基础设施服务控制功能以及它们需要如何行为。这些模型和决策不特定于技术，也不取决于所选择的特定软件解决方案。

本文档中的用例大多设想为一种蜘蛛网类型的架构，该架构具有层次结构，可以自动扩展端点数量。根据需要，可以在架构的每个层次上选择自主程度，以支持、管理和扩展大规模分布式系统。边缘节点之间的网络连接需要关注可用性和可靠性，而不是带宽和延迟。

本节涵盖两种常见的高级架构模型，展示了两种不同的方法。它们是集中式控制平面和分布式控制平面模型。由于这是一个高级讨论，假设边缘将具有足够的计算、存储和网络功能来满足基本需求；任何专门的配置或功能均不在讨论范围内。架构模型还显示了每个站点所需的功能，但并未讨论如何使用任何特定解决方案（例如 Kubernetes、OpenStack 等）来实现它。但是，在开发模型期间考虑的方面和工具包括

• 管理大量边缘数据中心的挑战：边缘数据中心可用功能与编排开销
• 准备架构以一次处理一个故障：例如，与中央或区域数据中心的网络连接丢失或降级
• 在小占地面积上提供最小可行功能

还有其他研究涵盖了类似的架构考虑因素，并具有相似的特征，但并不完全符合其中一种模型。例如，最近的 研究提出了一种颠覆性方法，包括在不同地理位置运行独立的 OpenStack 安装，并在需要时进行协作。该方法提供了单一连接系统的错觉，而无需进行侵入性更改。

讨论和开发有关将存储解决方案和进一步的新组件集成到边缘架构中的要求和解决方案的更多细节是 OSF 边缘计算组的未来工作的一部分。

集中式控制平面

对于集中式控制平面模型，边缘基础设施构建为传统的单个数据中心环境，该环境通过 WAN 连接在控制器和计算节点之间进行地理分布。如果分布式节点与其他节点断开连接，则分离的节点可能无法正常运行的风险。

由于该模型的限制，节点严重依赖于中央数据中心来承担边缘计算、存储和网络服务的管理和编排负担，因为它们运行所有控制器功能。计算服务包括运行裸机、容器化和虚拟化工作负载。与执行基础设施工作负载相关的函数分布在中央和边缘数据中心之间。

上图显示，所有关键控制功能都位于中央站点，包括所有身份管理和编排功能。抛开地理分布的性质不谈，这种方法面临着与运营大型数据中心非常相似的挑战。从有利的一面来说，它提供了对整个基础设施的集中视图，这从运营角度来看具有其优势。

虽然管理和编排服务是集中的，但该架构对网络连接丢失的故障的弹性较差。边缘数据中心没有完全的自主权，因此，如果无法访问镜像库或身份管理服务，则分发配置更改可能会失败。如果用例要求工作负载高度可用（例如，零售部署中的销售点系统或物联网场景中的工业机器人），则配置需要允许应用程序即使在网络中断的情况下也能继续运行。这可能具有挑战性，因为大多数数据中心为中心的部署在无法访问时将计算节点视为失败的资源。此外，身份提供者 (IdP) 服务可以放置在中央数据中心或远程连接到身份管理服务，这限制了用户管理和身份验证。根据情况，这可能被认为更安全，因为控制器是集中的，或者更灵活，因为它可能意味着在关键时刻用户无法访问。

通常，构建此类架构会使用来自知名项目（如 OpenStack 和 Kubernetes）的现有软件组件作为构建块。一些边缘站点可能只有容器化的工作负载，而其他站点可能正在运行虚拟机。建议查看 TripleO 的分布式计算节点 (DCN) 部署配置，该配置与此模型一致。

总而言之，该架构模型不能满足所有用例，但它为现有的架构提供了一个演进路径。此外，它还适合于不需要自主行为的场景。

分布式控制平面

更大的用例集要求边缘站点能够更充分地独立运行。这意味着它们对网络连接问题的弹性更强，并且能够最大限度地减少边缘站点之间的延迟造成的影响。

分布式控制平面模型定义了一种架构，其中大多数控制服务驻留在大型/中型边缘数据中心。这提供了一种编排开销，可以同步这些数据中心并同时将它们作为更大的连接环境的一部分进行管理。

可以使用不同的选项来克服该模型的运营挑战。一种方法是使用联合技术来连接数据库以整体运行基础设施；另一种选择是在站点之间同步数据库，以确保它们具有相同的配置工作集。该模型仍然允许存在具有小占地面积的小型边缘数据中心，在这种情况下，计算服务的数量有限，并且倾向于将可用的大部分资源用于工作负载。

最常见的示例是根据场景选择身份管理服务的组件位置，以及上述方法之一来连接它们。选择取决于各个用例的特征和所用软件组件的功能，因为每种配置的整体行为和管理方式都不同。例如，使用 OpenStack 身份管理服务 (Keystone) 将其定位到边缘部署中，而无需限制技术，因为其 API 支持 OpenStack 和 Kubernetes 或两者的组合。

如果发生网络连接丢失，该架构模型更加灵活，因为所有修改工作负载或执行用户管理操作所需的本地服务都可用。仍然存在潜在的障碍，例如由于存储和缓存大小的限制，并非所有镜像都可用本地。由于将大量控制功能分布在地理上分散的环境中，管理编排类型服务变得更加复杂，这也带来了新的挑战。

与前一种情况类似，该架构支持 OpenStack 和 Kubernetes 服务的组合，这些服务可以分布在环境中以满足每个站点所需的所有功能。一个例子是 StarlingX，其架构与分布式模型非常相似。

市场上存在混合解决方案，试图通过在中央节点以及大型/中型边缘数据中心中部署完整的安装，并在其之上使用编排类型服务（例如 ONAP，电信行业中使用的编排工具）来利用两者的优势。

未来架构考量

上述模型仍在开发中，因为在特定领域收集了更多需求和要求，例如

• 存储：考虑因素包括本地存储以实现高性能和低延迟的数据处理，以及提供连接到远程存储解决方案的选项。有几种替代方案可用，从小型且简单的系统（如软件 RAID 或 LVM）到大型且高度可靠的分布式存储管理器（如 Ceph）。
• 裸机管理：它可以在多个层次上引入，一个是需要管理和扩展其基础设施以包括零触控配置方法的 инфраструктура оператор，另一个是基础设施的用户，他们可能会获得创建新边缘站点的权限和选项。

还有其他研究涵盖了类似的架构考虑因素，并具有相似的特征，但并不完全符合其中一种模型。例如，最近的 研究提出了一种颠覆性方法，包括在不同地理位置运行独立的 OpenStack 安装，并在需要时进行协作。该方法提供了单一连接系统的错觉，而无需进行侵入性更改。

讨论和开发有关将存储解决方案和进一步的新组件集成到边缘架构中的要求和解决方案的更多细节是 OSF 边缘计算组的未来工作的一部分。

测试考量

定义边缘解决方案的常见架构本身就是一个复杂的挑战，但这仅仅是旅程的开始。下一步是能够部署和测试该解决方案，以验证其功能并确保其按预期执行。由于边缘架构仍处于早期阶段，重要的是能够识别每种模型的特征的优点和缺点，以确定最适合给定用例的方案。

OpenStack 和 Kubernetes 的边缘部署构建块已经可用。这两个都是开源项目，具有广泛的测试工作，可在开放环境中提供。虽然通常会对代码库执行功能和集成测试以及可扩展性和稳健性检查，但这些部署很少扩展到一台或几台物理服务器。在边缘架构的情况下，检查旨在克服基础设施地理分布的功能至关重要，尤其是在架构模型的配置基本不同的情况下。为了确保稳定和可信的结果，建议参考科学界的最佳实践，以找到最稳健的解决方案。一种常见的标准做法是 工件审查和徽章 方法。

测试既是一门艺术，也是一个精确的工程过程。在较低级别上测试代码，例如单元测试或通过 API 测试检查组件的响应，是直接的。这允许创建支持运行自动化单元测试套件的框架，该套件解决诸如可重复性、可复制性和可重现性之类的要求。测试集成的系统以模拟生产环境的配置和环境可能非常具有挑战性。下图描述了执行实验活动时执行的一般过程。该过程，应用于研究领域，也可以用于帮助构建新的组件和解决方案，以满足边缘计算用例的要求，即使某些步骤仍然需要更多的工具来执行所有检查，就像它们是简单的单元测试一样。

第一步看似微不足道，描述了从测试平台获取资源，这不特定于边缘计算场景。分配的资源（例如，计算、存储、网络）代表用于进行评估的物理基础设施。

第二阶段更具挑战性。它包含多个子步骤，用于准备物理基础设施以及被测系统 (SUT) 的部署。由于边缘环境可能非常复杂，因此还需要测试它们在不可靠的网络连接等情况下准备的能力。因此，首选支持声明式方法的部署工具，以指定基础设施的特征，例如延迟、吞吐量和网络丢包率，以模拟目标实际场景和情况。

一旦创建了部署计划并选择了资源，在安装应用程序和服务之前，需要在预部署阶段确认基础设施配置正确。这在边缘架构中尤其重要，因为资源必须通过复杂的网络拓扑可用。例如，配置文件属性可能都已正确设置，但所有资源是否可达、状态良好，并且能够按预期相互通信？检查可以像双向使用 ping 命令、验证特定网络端口是否打开等等这样简单。此过程的目的是确保部署步骤能够成功完成，并产生符合需求和计划的测试环境。边缘架构的复杂性通常需要细粒度和强大的预部署验证框架。

现在测试床已经准备并测试完毕，下一步是在基础设施上部署软件应用程序。对于基于 OpenStack 和 Kubernetes 服务等环境构建的系统，Kolla、TripleO、Kubespray 或 Airship 等框架可以作为起点。请注意，这些工具中的大多数都是以单个数据中心的限制为范围而设计的，这意味着它们假定环境在运行期间可以进一步扩展，而边缘基础设施是地理分布式的，并且远程节点通常资源有限。此外，不同模型之间的配置选项也差异很大。作为边缘架构测试的一部分，需要验证部署工具，以确定可以针对这些场景进行调整和重用的工具。为了确保测试成功，安装本身需要进行验证，例如，检查服务以确保它们已正确安装和配置。此操作最好是部署工具的功能。

在完成所有准备工作后，下一步是基准测试整个集成框架。基准测试通常被定义为性能测试，但此处它适用于更广泛的范围，包括集成和功能测试。同样重要的是要注意，测试套件可能严重依赖于用例，因此需要针对所使用的架构模型进行微调。虽然存在一些工具可以执行网络流量整形和故障注入，但挑战更多地在于识别代表上述边缘用例的值。

构建边缘基础设施由各种众所周知的组件组成，这些组件最初并非专门为边缘用例而实现。因此，在这些环境中，有时需要测试基本功能，以确保它们在其他场景中也能按预期工作。示例功能包括

• 创建/删除资源（用户、flavor、镜像等）；范围：一个或多个边缘站点
• 列出实例（VM、容器）；范围：一个边缘站点或“单窗”仪表板
• 创建跨数据中心网络资源

边缘基础设施的进一步测试需要考虑所选的架构模型

• 在集中式控制平面模型中使用 OpenStack 依赖于 OpenStack 网络连接即服务 (Neutron) 组件的分布式虚拟路由器 (DVR) 功能。
• 在网络连接中断的情况下，边缘数据中心的行为可能因架构模型而异。在某些情况下，决策可能是选择配置系统以在实例运行时保持运行，而在其他情况下，正确的做法是在站点隔离时销毁工作负载。除了这些考虑因素外，由于可能的资源限制，自动缩放等功能的期望也会有所不同，这些都需要反映在测试套件中。

最后两个步骤是微不足道的。需要收集和评估测试结果，然后将 SUT 基础设施恢复到其原始状态。

Enos (https://enos.readthedocs.io/en/stable/provider/openstack.html)、Enos-Kubernetes (https://pypi.ac.cn/project/enos-kubernetes) 和 enoslib (https://gitlab.inria.fr/discovery/enoslib) 等工具在实验驱动的研究社区中可用，用于评估通过广域网 (WAN) 连接在分布式环境中 OpenStack 和 Kubernetes。它们可以扩展或用作示例解决方案，用于执行上述过程以评估边缘的一些架构选项。需要进一步的组件来确保能够测试更复杂的环境，在这些环境中，越来越多的构建块相互集成。

结论

边缘计算高度依赖于在云中吸取的经验教训和实施的解决方案。即使大多数构建块都可用于创建满足大多数要求的环境，但这些组件中的许多都需要进行微调或 API 扩展，以提供更优化和更适合目的的解决方案。新的架构考虑因素进一步突出了部署和测试要求，因此需要增强、定制，并在某些情况下从头设计和实现现有解决方案。

真正的挑战在于对新概念和不断发展的架构模型的有效和彻底测试。需要识别新的测试用例以及代表典型情况和系统故障的值。测试可以帮助增强架构考虑因素以及识别不同解决方案的不足之处。

正如这些讨论所示，与边缘计算相关的创新和软件演进仍处于早期阶段。是的，有一些正在生产中运行的系统至少类似于某些考虑因素——例如 uCPE 或 vRAN 部署。此处讨论的架构模型涵盖了大多数用例，但是，它们仍然需要额外的努力来详细说明所需的功能，以超越基础知识，概述进一步优选的解决方案并记录最佳实践。

现在是 IT 行业中的各个团体（开放团体、半开放或封闭联盟以及标准化机构）合作采取下一步行动以进行架构设计和测试的最佳时机，以便能够满足各种边缘计算用例的需求。考虑到所需的高度集成，各个组件的主题专家开始为共同努力做出贡献至关重要。

作者

• Beth Cohen，Verizon 技术人员杰出成员
• Gergely Csatári，诺基亚资深开源专家
• Shuquan Huang，99Cloud 技术总监
• Bruce Jones，StarlingX 架构师兼项目经理，英特尔公司
• Adrien Lebre，IMT Atlantique / Inria / LS2N 计算机科学教授
• David Paterson，戴尔科技公司高级首席软件工程师
• Ildikó Váncsa，OpenStack 基金会生态系统技术负责人