白皮书下载 | 善用异构性，发展边缘计算

点击上方 Arm 社区 关注我们

实现智能边缘面临着三大挑战，分别是：实现硬件异构性、克服开发中遇到的阻碍，以及确保大规模安全性。本文将重点围绕异构性进行探讨，内容涵盖异构性的出现、对系统的影响，以及解决此类固有挑战的一些思路。想要了解更多有关智能边缘的信息，欢迎阅读《边缘计算演进》白皮书。

长按/扫描左方二维码

云计算基础设施的特点是同构性，而边缘计算基础设施的特点则是异构性。边缘侧基础设施的异构性主要源于严苛的环境、节点的高昂安装成本和自然增长特性（长期使用的基础设施）。然而造成边缘侧多样化的这些驱动因素在云端并不存在。边缘计算之所以使用异构解决方案，是因为此类解决方案可通过提供不同级别的算力来增强设计空间。各种设计配置能够应对成本、尺寸、功率和能耗等不同方面的问题。异构性会出现在节点内部。一个节点可能包含多个不尽相同的处理器，例如，不同的 Arm 架构产品系列（如 Arm Cortex-A 和 Cortex-M）、不同的性能和尺寸、大小核技术，或是专用工作负载的加速器。边缘计算中的异构性还可能出现在节点之间，例如，随着时间推移，同一平台上部署了多代产品。

使用云原生开发工具已证实能为云端开发者缩短产品上市时间、简化编程、提供可移植性并实现可管理的部署。同样地，云工具和方法可为边缘侧开发者提供类似的优势，然而，异构性所带来的挑战不容忽视。其原因在于此类云工具忽略了异构性及其影响，或是采用了过于简单的解决方案。

应用的服务质量 (QoS) 是受异构性影响的主要方面之一。服务质量管理也是边缘计算基础设施的主要要求。如果各类应用的每个组件都能获得足够的资源，服务质量便能得到保证。在系统设计的所有运行情况下，边缘侧的服务质量也应该保证。应用或应用元数据会提供有关资源要求的信息，边缘侧的基础设施应保证这些资源的可用性。任何共享资源都可能出现争用情况，因此必须加以管理。

异构性改善了设计空间，但也增加了复杂性，而降低复杂性是维持优势的关键。下图展示了我们为降低两种异构性情况的复杂性所探索的方案。

当前的编排器假定节点只在核心数量和内存容量方面有所不同，这意味着任何一个核心都能提供类似算力。但现实情况是，如果某个应用组件是为配备 Cortex-A76 核心的节点（例如树莓派 5）而设计的，当其在配备 Cortex-A72 核心的节点（例如树莓派 4）上运行时，表现将截然不同。然而，从编排器的角度来看，节点的能力是相同的。为此，我们曾提出了针对该问题的解决方案，即引入参考核心的概念。在这种情况下，与参考核心相比，每个节点都能提供预期的算力。应用会依据参考核心来指定计算资源要求，并期望在不同节点上运行时，能够获得足够的算力，从而实现预期的服务质量。对于大小核技术的特殊情况，即同一节点上存在不同类型的核心，可为用于运行应用的核心类型进行资源要求转换，以解决此类情况。

混合节点提供多个计算单元，这些计算单元具有不同的架构，而且可能运行着不同的操作系统和基础软件。混合节点中可能存在其他核心，例如微控制器核心（如 Cortex-M4）、实时核心和加速器等。在这种情况下，主要要求是可移植性、易编程性和易部署性。即便是具有类似指令集架构和产品系列（如 Cortex-A、Cortex-M 和 Cortex-R 系列）的核心，使用云原生工具来创建可部署、可维护的解决方案也并非易事。

为解决前面提到的一些问题，我们在另一篇文章 ^[1] 中曾概述了一个概念验证，展示了如何使用云原生编排工具将应用从 Cortex-A 部署到混合系统中的 Cortex-M 上。在该解决方案中，应用可划分为多个部分，根据要求的不同，每个部分在不同核心上运行。如此一来，固件更新变得简单、安全，并且可规模化控制。例如，通过使用混合运行时，可按需更新 Cortex-M 上运行的内容，从而升级功能。在这种情况下，可以降低复杂性，并更好地利用这些额外的计算元素。

* 本文为 Arm 原创文章，转载请留言联系获得授权并注明出处。