通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

Edge 工作负荷配置模式

车间中的各种系统和设备都可能导致工作负荷配置成为一个难题。 本文提供了解决它的方法。

上下文和问题

制造业公司作为数字化转型之旅的一部分，越来越注重构建可重复使用为共享功能的软件解决方案。 由于车间的各种设备和系统，模块化工作负载配置为支持不同的协议、驱动程序和数据格式。 有时，甚至多个工作负荷实例也会在同一边缘位置使用不同的配置运行。 对于某些工作负荷，配置每天更新多次。 因此，配置管理对横向扩展边缘解决方案越来越重要。

解决方案

边缘工作负荷的配置管理有一些常见特征：

  • 有几个配置点可以分组到不同的层，如软件源、CI/CD 管道、云租户和边缘位置： 特征化工作负荷配置的层图：软件源、C I/C D 管道、云租户和边缘位置。
  • 不同的人员可以更新各个层。
  • 无论配置如何更新，都需要仔细跟踪和审核这些配置。
  • 为了保持业务连续性，需要在边缘脱机访问配置。
  • 此外，还需要提供云中可用的配置的全局视图。

问题和注意事项

在决定如何实现此模式时，请考虑以下几点：

  • 当边缘未连接到云时允许编辑会显著增加配置管理的复杂性。 可以将更改复制到云，但存在以下难题：
    • 用户身份验证，因为它依赖于云服务（如 Microsoft Entra ID）。
    • 重新连接后的冲突解决问题（如果工作负载收到需要手动干预的意外配置）。
  • 如果拓扑符合 ISA-95 要求，则边缘环境可以具有与网络相关的约束。 可以通过选择跨层提供连接的技术（例如 Azure IoT Edge 中的设备层次结构）来克服这种限制。
  • 如果运行时配置与软件版本分离，则需要单独处理配置更改。 若要提供历史记录和回滚功能，需要在云中的数据存储中存储过去的配置。
  • 配置中的故障（如配置为不存在的终结点的连接组件）可能会中断工作负荷。 因此，请务必在可观测性解决方案中处理其他部署生命周期事件时处理配置更改，以便可观测性仪表板有助于将系统错误与配置更改相关联。 有关可观测性的详细信息，请参阅 云监视指南：可观测性。
  • 了解云和边缘数据存储在业务连续性中扮演的角色。 如果云数据存储是单一事实来源，则边缘工作负载应能够使用自动化过程还原预期状态。
  • 为了复原，边缘数据存储应充当脱机缓存。 这比延迟考虑更优先。

何时使用此模式

在以下情况下使用此模式：

  • 要求在软件发布周期之外配置工作负荷。
  • 不同的用户需要能够读取和更新配置。
  • 即使没有与云的连接，配置也需要可用。

示例工作负荷：

  • 连接到车间资产来引入数据的解决方案（例如 OPC Publisher），以及命令和控制
  • 用于预测性维护的机器学习工作负荷
  • 在生产线上实时检查质量的机器学习工作负载

例子

在运行时配置边缘工作负荷的解决方案可以基于外部配置控制器或内部配置提供程序。

外部配置控制器变体

外部配置控制器变体的体系结构示意图。

此变体具有在工作负载外部的配置控制器。 云配置控制器组件的角色是通过边缘配置控制器将编辑从云数据存储推送到工作负荷。 边缘还包含数据存储，以便系统即使在与云断开连接时也能正常运行。

使用 IoT Edge 时，边缘配置控制器可以作为模块实现，配置可以与 模块孪生一起应用。 模块孪生有大小限制；如果配置超出限制，可以通过使用 Azure Blob 存储或通过直接方法分块更大的有效负载来扩展解决方案。

此变体的优点包括：

  • 工作负载本身无需知道配置系统。 如果工作负荷的源代码不可编辑，则此功能是必需的，例如，使用 Azure IoT Edge 市场的模块时。
  • 可以通过通过云配置控制器协调更改来同时更改多个工作负荷的配置。
  • 可将其他验证作为推送管道的一部分实现，例如，在将配置推送到工作负荷之前，验证边缘是否存在终结点。

内部配置提供程序变体

内部配置提供程序变体的体系结构示意图。

在内部配置提供程序变体中，工作负载从配置提供程序获取配置。 有关实现示例，请参阅 在 .NET 中实现自定义配置提供程序。 该示例使用 C#，但可以使用其他语言。

在此变体中，工作负荷具有唯一标识符，以便在不同环境中运行的相同源代码可以有不同的配置。 构造标识符的一种方法是将工作负荷的分层关系连接到顶级分组，例如租户。 对于 IoT Edge，它可以是 Azure 资源组、IoT 中心名称、IoT Edge 设备名称和模块标识符的组合。 这些值共同构成了一个唯一标识符，用作数据存储中的密钥。

虽然模块版本可以添加到唯一标识符中，但在软件更新中保存配置是一个常见的需求。 如果版本是标识符的一部分，则应通过附加实现向前迁移旧版本的配置。

此变体的优点包括：

  • 除了数据存储之外，解决方案不需要组件，降低了复杂性。
  • 可以在工作负荷实现中处理来自不兼容旧版本的迁移逻辑。

基于 IoT Edge 的解决方案

物联网边缘架构变体的示意图。

IoT Edge 参考实现的云组件由充当云配置控制器的 IoT 中心组成。 Azure IoT 中心的模块孪生功能通过使用模块孪生的期望属性和报告属性来传播配置更改及当前应用配置的信息。 配置管理服务充当配置的来源。 它也可以是用于管理配置、生成系统以及用于创作工作负荷配置的其他工具的用户界面。

Azure Cosmos DB 数据库存储所有配置。 它可以与多个 IoT 中心交互，并提供配置历史记录。

边缘设备通过报告的属性指示应用了配置后，配置状态服务会记下数据库实例中的事件。

在配置管理服务中创建新配置时，它将存储在 Azure Cosmos DB 中，边缘模块的所需属性将更改到设备所在的 IoT 中心。 然后，IoT 中心将配置传输到边缘设备。 边缘模块应通过模块孪生应用配置和报告配置的状态。 然后，配置状态服务侦听孪生更改事件，并在检测到模块报告配置状态更改时，记录 Azure Cosmos DB 数据库中的相应更改。

边缘组件可以使用外部配置控制器或内部配置提供程序。 在任何一种实现中，配置可以通过模块双胞胎期望属性进行传输。如果需要传输大型配置，模块双胞胎期望属性则会包含指向 Azure Blob 存储或其他可用于检索配置的服务的 URL。 然后，该模块在模块孪生的报告属性中指示新配置是否已成功应用，以及当前应用了哪些配置。

供稿人

本文由Microsoft维护。 它最初是由以下贡献者撰写的。

主要作者：

若要查看非公开的LinkedIn个人资料，请登录LinkedIn。

后续步骤