Microsoft AZ-305: 集成与消息传递架构 — 学习指南

By Laurynas Brazys · 11 August 2026 · #microsoft #az-305 #certification #exam-prep #study-guide

属于 Microsoft Azure Solutions Architect Expert AZ-305 — 学习指南. 使用经过验证的答案练习： Microsoft 考试中心, 或参加限时模拟考试： ExamRoll.io.

概述

Azure 上的集成与消息传递架构取决于为命令、事件和数据移动语义选择正确的服务；为可靠性、顺序和规模进行设计；以及安全地集成混合系统。核心构建块包括：用于企业级消息传递并提供丰富代理功能的 Azure Service Bus、用于反应式事件路由的 Azure Event Grid、用于高吞吐量流式引入的 Azure Event Hubs，以及用于简单队列的 Storage Queues。围绕这些核心服务的是：用于流程自动化的 Azure Logic Apps、用于治理和开发者体验的 API Management、用于 ETL/ELT 的 Azure Data Factory、用于防火墙友好的本地连接的 Azure Relay，以及用于移动推送的 Azure Notification Hubs。良好的设计会为特定任务选择合适的服务，明确地对契约和故障模式进行建模，并在适当的情况下应用编排或协同模式。

Azure 上的消息传递与事件处理

Azure Service Bus 是用于命令和工作流的企业级代理，适用于需要有序交付、事务、组内 FIFO 以及死信处理的场景。队列在单个生产者和一个竞争性消费组之间提供点对点消息传递。主题支持发布/订阅 (pub/sub) 模式，可拥有多个独立的订阅，这些订阅可以使用类 SQL 的筛选器和操作来筛选和路由消息。消息会话将相关消息分组到一个 sessionId 下，从而实现按组的 FIFO 和有状态处理；会话锁确保在同一时间只有一个消费者处理一个会话。当超过最大交付计数、TTL 过期或被显式地置于死信队列时，死信队列会捕获毒性消息，从而可以进行隔离和后续检查；每个队列或订阅都有一个 $DeadLetterQueue 子队列。事务允许在同一命名空间内的实体之间执行原子的发送/接收/完成操作，例如，确保只有在后续消息成功发送后，当前消息才被完成（send-via 支持跨实体工作流）。

Azure Event Grid 是一个完全托管的事件路由器，用于反应式、基于推送的模式。它使用原生的 Event Grid 架构或 CloudEvents 1.0。事件订阅以 Functions、Logic Apps、Service Bus、Event Hubs、WebHooks 和 Storage Queues 等端点为目标，并使用主题和高级筛选器来减少噪音。交付会以指数退避方式重试；订阅支持可配置的重试策略（最大交付尝试次数和事件生存时间），并可将无法交付的事件置于死信队列，存入一个 Storage 帐户。握手验证可保护 WebHook 端点，而托管标识则简化了向 Azure 端点的发布和交付过程。

Azure Event Hubs 通过分区日志大规模引入遥测和流式数据。分区提供并行性以及分区内的顺序；选择一个分区键来保持相关事件的有序性。分区数量决定了规模，并且在创建后无法减少，因此需要为未来的吞吐量规划大小。消费者组为不同的应用程序提供事件流的独立视图，而不会相互干扰各自的偏移量。Capture 功能根据时间/大小窗口，以近乎实时的方式将数据持久地卸载到 Azure Blob Storage 或 Data Lake Storage，通常采用 Avro 格式，从而可以在不影响引入的情况下进行批量分析。内置的 Schema Registry 存储带有版本控制和兼容性策略的 Avro/JSON 模式，使生产者和消费者能够安全地验证和演进契约。

Storage Queues 提供简单、经济高效的至少一次交付，具有可见性超时和通过消息 TTL 及应用程序管理的毒性消息处理实现的基本死信功能。它们缺少事务、会话和高级路由功能，但在以低成本实现基本解耦和大规模扇出方面表现出色。

如何选择：

当命令、工作流和集成场景需要 FIFO（通过会话）、事务、延迟、重复检测和死信审计时，使用 Service Bus。
当需要来自 Azure 服务或自定义应用的轻量级、基于推送的扇出通知，并具备精细筛选和近乎实时的反应能力时，使用 Event Grid。
当需要高吞吐量的流式遥测和日志引入，并有独立的消费者和下游分析时，使用 Event Hubs。
当只需要简单的生产者/消费者解耦，不需要高级代理功能，且成本简单性至关重要时，使用 Storage Queues。

集成、API 与混合连接

Azure Logic Apps 提供托管的工作流自动化服务，拥有数百个连接器。在消耗（多租户）模式下，您按操作付费，具有自动缩放和多租户连接器；非常适合突发性使用场景。标准（单租户）模式在 Functions 运行时上运行，支持有状态/无状态工作流、更高的吞吐量、自定义连接器和进程内运行的内置连接器、容器化、本地开发以及 VNET/专用终结点集成；非常适合需要企业级隔离和可预测容量的场景。集成服务环境 (ISE) 是一个用于专用网络和数据局部性的旧版专用实例；新设计通常倾向于使用带 VNET 集成的 Logic Apps Standard 或部署到 App Service Environment v3。

Azure API Management (APIM) 为 API 提供了一个抽象和治理层。策略应用于入站、后端和出站阶段，以强制执行横切关注点，例如 validate-jwt、rate-limit-by-key、quota、set-header、retry、cache-lookup/store 以及用于动态路由的 set-backend-service。产品（Products）将一个或多个 API 分组，捆绑策略行为，并可发布到特定组。订阅（Subscriptions）按使用者或按产品颁发密钥，以计量和控制访问；密钥可以轮换并与配额绑定。开发人员门户支持自助服务发现、文档、试用和入门工作流，而自承载网关则允许为本地或其他云环境进行混合控制平面/边缘部署。

Azure Relay 无需打开入站防火墙端口，即可实现到本地服务的入站连接。混合连接（Hybrid Connections）使用基于 TLS 443 的 WebSockets 进行通用的双向套接字通信，该通信由本地出站发起，并从客户端连接到 Relay，适用于 HTTP 和封装在 WebSockets 上的任意协议。WCF 中继（WCF Relay）通过中继公开本地 WCF 终结点 (NetTcp/HTTP)，提供传输层或消息层安全性以及基于声明的访问；它非常适合需要安全、防火墙友好的方式来公开现有 WCF 服务的场景。

Azure Notification Hubs 是一个跨平台的推送代理，它抽象了各种平台通知系统（PNS），如用于 iOS 的 APNs、用于 Android 的 FCM、用于 Windows 的 WNS 和用于 Amazon 的 ADM。后端使用标签和模板注册设备或安装，以大规模地定向和个性化通知。每个 PNS 都需要平台凭据：APNs p8 密钥或证书、FCM 服务器密钥/凭据、WNS 包 SID/机密。Notification Hubs 处理扇出、限制和令牌管理，因此应用程序代码可以保持与 PNS 无关。

数据移动与流分析

Azure Data Factory (ADF) 在混合资产间编排数据集成。集成运行时 (IR) 为活动托管计算资源：Azure IR 用于 Azure 内的无服务器复制和数据流，自承载 IR 用于专用网络内的数据移动/计算而无需打开入站端口，Azure-SSIS IR 用于将 SSIS 包直接迁移（lift-and-shift）到托管集群。管道通过控制流（依赖关系、循环、分支、触发器）和参数化来编排活动，以实现重用。映射数据流提供大规模、无代码、基于 Spark 的转换，并具备架构偏移处理和分区控制功能；当转换复杂但您希望使用托管计算时，可使用此功能。链接服务定义源、接收器和计算的连接元数据及凭据；数据集和数据流的源/接收器会引用这些链接服务，从而实现安全重用和 RBAC。

Event Hubs 通过 Capture 功能将数据捕获到持久化存储中，从而与分析服务集成，然后 Azure Synapse 或 Databricks 可以用微批处理的方式处理这些 Avro 文件。架构注册表（Schema Registry）通过集中化契约，简化了流式作业中的反序列化和架构演变，避免了生产者和消费者之间脆弱的、隐式的类型定义。

← 安全架构与零信任 · 所有领域 · 监控、成本优化与运维 →

练习这些题目 → · 在 ExamRoll.io 上限时练习 →