通过

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

边缘工作负荷配置模式

  • 项目

由于车间系统和设备种类繁多，使得配置工作负载困难重重。 本文介绍了解决此问题的方法。

上下文和问题

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

解决方案

针对边缘工作负载的配置管理有以下共同特征：

  • 有几个配置点可以分为不同的层，例如软件源、CI/CD 管道、云租户和边缘位置：描述工作负载配置特征的分层图：软件源、CI/CD 管道、云租户和边缘位置。
  • 不同层可以由不同人员进行更新。
  • 无论如何更新配置，都需要继续详细跟踪和审核。
  • 为了实现业务连续性，需要可以在边缘脱机访问配置。
  • 此外，还需要关于可在云中使用的配置的全局视图。

问题和注意事项

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

  • 当边缘未连接到云时，允许进行编辑会显著增加配置管理的复杂性。 可以将更改复制到云，但存在以下问题：
    • 用户身份验证问题（因为它依赖于 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 的解决方案

该图显示了基于 I o T Edge 变体的体系结构。

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

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

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

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

边缘组件可以使用外部配置控制器或内部配置提供程序。 在任一实现中，配置或是在模块孪生的必需属性中传输，或是在需要传输大型配置的情况下，模块孪生的必需属性包含指向 Azure Blob 存储或另一个可用于检索配置的服务的 URL。 然后，模块在模块孪生报告的属性中发出信号，指示是否成功应用新配置以及当前应用了什么配置。

作者

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

主要作者：

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

后续步骤