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