此示例体系结构基于基本企业集成体系结构。 它将后者进行了扩展，以展示如何集成企业后端系统，使用消息代理和事件来分离服务，以提高可伸缩性和可靠性。 确保了解该设计，以及基本集成体系结构中使用的组件。 该设计提供了有关此体系结构核心组件的基础信息，此处不再赘述。
体系结构
本设计中引用的后端系统可能包括软件即服务 (SaaS) 系统、Azure 服务和企业中的现有 Web 服务。
下载此体系结构的 Visio 文件。
工作流
此处显示的体系结构在更简单的体系结构上构建，后者显示在基本企业集成中。 该体系结构使用逻辑应用直接与后端系统协调工作流，并使用 API 管理创建 API 目录。
此版体系结构添加了两个组件，使系统的可靠性和可伸缩性更高：
Azure 服务总线。 服务总线是安全且可靠的消息代理。
Azure 事件网格。 事件网格是事件路由服务。 它使用发布/订阅 (pub/sub) 事件模型。
与对后端服务进行直接的同步调用相比，使用消息代理的异步通信具有以下优势：
- 通过基于队列的负载均衡模式提供负载均衡，以便处理工作负荷突增的情况。
- 提供用于通过发布者-订阅者模式将消息广播到多个使用者。
- 可靠地跟踪长时间运行的工作流的进度，此类工作流涉及多个步骤或多个应用程序。
- 有助于分离应用程序。
- 与现有的基于消息的系统集成。
- 当后端系统不可用时，允许将工作排队。
有了事件网格，系统中的各种组件就可以在事件发生时做出反应，不必依赖轮询或计划的任务。 与消息队列和主题一样，它有助于分离应用程序和服务。 应用程序或服务可以发布事件，任何相关的订阅方都会获得通知。 可以在不更新发送方的情况下添加新的订阅方。
许多 Azure 服务支持将事件发送到事件网格。 例如，将新文件添加到 Blob 存储时，逻辑应用可以侦听事件。 此模式可启用反应式工作流，即上传某个文件或将消息置于队列中会启动一系列过程。 这些过程可能并行执行，也可能按特定顺序执行。
建议
基本企业集成中描述的建议适用于此体系结构。
服务总线
服务总线有两种传递模式 - 拉取或代理推送。 在拉取模型中，接收方会持续轮询新消息。 轮询可能效率不高，尤其是在有许多队列且每个队列都收到一些消息的情况下，或者是在两个消息的时间间隔很长的情况下。 在代理推送模型中，服务总线会在有新消息时通过事件网格发送事件。 接收方可订阅事件。 触发事件时，接收方可从服务总线拉取下一批消息。
创建逻辑应用来使用服务总线消息时，建议将代理推送模型与事件网格集成配合使用。 它通常更经济有效，因为逻辑应用不需轮询服务总线。 有关详细信息，请参阅 Azure 服务总线到事件网格的集成概述。 目前，服务总线高级层是事件网格通知所需的。
请使用 PeekLock 来访问一组消息。 使用 PeekLock 时，逻辑应用可以执行步骤来验证每条消息，然后完成或放弃该消息。 此方法可以防范意外的消息丢失。
事件网格
事件网格触发器的触发意味着发生了“至少 1 个”事件。 例如，逻辑应用在获取服务总线消息的事件网格触发器时，应假定可能需要处理多个消息。
注意事项
这些注意事项实施 Azure 架构良好的框架的支柱原则，即一套可用于改善工作负载质量的指导原则。 有关详细信息，请参阅 Microsoft Azure 架构良好的框架。
可靠性
可靠性可确保应用程序符合你对客户的承诺。 有关详细信息，请参阅可靠性支柱概述。
- Microsoft Entra ID：：Microsoft Entra ID 是一个全球分布式、高度可用的 SaaS 平台。 有关保证可用性的详细信息，请参阅 SLA。
- API 管理：根据业务需求和成本承受能力，API 管理可以部署在多种高度可用的配置中。 若要全面了解各个选项，请参阅确保 API 管理的可用性和可靠性。 有关保证可用性的详细信息，另请参阅 SLA。
- 逻辑应用：异地冗余存储可用于消耗计划层上的逻辑应用。 有关设计业务连续性和灾难恢复解决方案的信息，请参阅指南。 有关保证可用性的详细信息，另请参阅 SLA。
- 事件网格：主题、系统主题、域、事件订阅和事件数据的事件网格资源定义在区域中的三个可用性区域（可用时）之间自动复制。 当某个可用性区域发生故障时，事件网格资源会自动故障转移到另一个可用性区域，无需任何人工干预。 请参阅跨区域的异地灾难恢复，了解有关设计用于故障转移到另一个区域的灾难恢复解决方案的指南。 有关保证可用性的详细信息，另请参阅 SLA。
- 服务总线：服务总线高级版支持异地灾难恢复和可用性区域。 复制可用于服务总线标准版。 有关保证可用性的详细信息，另请参阅 SLA。
安全性
安全性针对蓄意攻击及滥用宝贵数据和系统提供保障措施。 有关详细信息，请参阅安全性支柱概述。
要保护服务总线，请使用与托管标识配对的 Microsoft Entra 身份验证。 服务总线资源的 Microsoft Entra 集成提供 Azure 基于角色的访问控制 (RBAC)，用于对客户端的资源访问进行精细控制。 可使用 Azure RBAC 授予对安全主体的权限，该主体可以是用户、组或应用程序服务主体（在本例中为托管标识）。
如果 Microsoft Entra ID 不可用，可以使用共享访问签名 (SAS)。 可以使用 SAS 身份验证向具有特定权限的用户授予对服务总线资源的访问权限。
如果需要将服务总线队列或主题公开为 HTTP 终结点（例如，以便发布新消息），请使用 API 管理将此终结点前置，以对其提供保护。 然后，可以适当地使用证书或 OAuth 身份验证来保护终结点。 保护终结点的最简单方法是使用包含 HTTP 请求/响应触发器的逻辑应用作为中介。
事件网格服务通过验证代码保护事件传送。 如果通过逻辑应用来使用事件，则会自动执行验证。 有关详细信息，请参阅事件网格安全性和身份验证。
网络安全
在整个设计过程中都应考虑网络安全。
- 服务总线高级版可以绑定到虚拟网络 (VNet) 子网服务终结点，从而保护命名空间，以便仅接受来自授权虚拟网络的流量。 此外，使用专用终结点将 VNet 流量锁定为通过专用链接的专用流量。
- 可以将逻辑应用标准版和高级版配置为通过专用终结点接受入站流量，并通过 VNet 集成发送出站流量。
- API 管理提供了多个选项，用于通过 Azure 虚拟网络保护对 API 管理实例和 API 的访问。 若要全面了解这些选项，请参阅将虚拟网络与 Azure API 管理结合使用文档。 还支持专用终结点。
成本优化
成本优化是关于寻找减少不必要的费用和提高运营效率的方法。 有关详细信息，请参阅成本优化支柱概述。
通常，使用 Azure 定价计算器来估算成本。 下面是一些其他注意事项。
API 管理
需要对所有运行的 API 管理实例付费。 如果已纵向扩展，但始终不需要该性能级别，请手动进行纵向缩减，或者配置自动缩放。
对于轻度使用工作负载，请考虑消耗层，这是一种低成本的无服务器选项。 消耗层按 API 调用计费，而其他层按小时计费。
逻辑应用
逻辑应用使用无服务器模型。 根据操作和连接器执行计算费用。 有关详细信息，请参阅逻辑应用定价。
服务总线队列、主题和订阅
服务总线队列和订阅支持代理推送和拉取模型来发送消息。 在拉取模型中，每个轮询请求都作为操作进行计量。 即使对于 30 秒（默认值）的长轮询，成本也可能很高。 除非需要实时发送消息，否则请考虑使用代理推送模型。
服务总线队列包含在所有层中（基本层、标准层和高级层）。 而服务总线主题和订阅在标准层和高级层中可用。 有关详细信息，请参阅 Azure 服务总线定价。
事件网格
事件网格使用无服务器模型。 根据操作（事件执行）数目计算费用。 操作包括事件到域或主题的流入、高级匹配项、发送尝试和管理调用。 可最多免费使用 100,000 个操作。
有关详细信息，请参阅事件网格定价。
有关详细信息，请参阅 Microsoft Azure 架构良好的框架中的“成本”部分。
卓越运营
基本企业集成参考体系结构提供有关 DevOps 模式的指南，这些模式与架构良好的框架的卓越运营要素保持一致。
尽可能自动执行恢复操作是卓越运营不可或缺的组成部分。 考虑到自动化，可以将 Azure 日志监视与 Azure 自动化结合使用以自动执行服务总线资源的故障转移。 有关启动故障转移的自动化逻辑示例，请参阅故障转移流文档中的图表。
性能效率
性能效率是指工作负载能够以高效的方式扩展以满足用户对它的需求。 有关详细信息，请参阅性能效率要素概述。
若要提高可伸缩性，服务总线高级层可以扩展消息传送单元数。 若要查看高级层的好处，请参阅服务总线高级和标准消息传送层文档。 此外，若要了解如何配置消息传送单元的自动缩放，请参阅自动缩放功能文档。
有关服务总线的其他建议，请参阅使用服务总线消息传送提高性能的最佳做法。
后续步骤
有关详细信息，请参阅服务总线文档：