Microsoft AZ-204: Azure 基于事件和消息的解决方案 — 学习指南

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

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

概述

Azure 的事件和消息产品组合涵盖四项互补的服务：用于反应式事件处理的 Event Grid、用于高吞吐量流式引入的 Event Hubs、用于企业消息传递和工作流协调的 Service Bus，以及用于移动推送的 Notification Hubs。要精通这些服务，需要了解每项服务的核心抽象、交付和重试语义、扩展模型，以及在典型的应用模式（如发布/订阅、命令处理、遥测数据引入以及设备或用户通知）中何时应优先选择某项服务。

Event Grid：主题、订阅、架构、筛选和死信处理

Event Grid 是一个用于处理离散事件的、完全托管的、基于推送的发布/订阅结构。发布者将事件发送到主题；订阅者在主题上注册事件订阅，并在支持的处理程序（如 HTTPS Webhook、Azure Functions、Logic Apps、Service Bus、Storage Queues 和 Event Hubs）上接收匹配的事件。Event Grid 定义了两种发布者模型。系统主题是 Azure 托管的主题资源，代表在您的订阅或资源组内发布事件的第一方 Azure 服务（例如，Storage Blob 创建、Key Vault 密钥轮换或 Resource Manager 事件）。自定义主题是用户创建的主题终结点，您的应用程序可以向其发布事件，从而在您自己的服务和域中实现事件驱动模式。系统主题无需发布者代码，简化了将 Azure 资源连接到反应式处理程序的过程；自定义主题则让您能够完全控制事件协定和生命周期。

Event Grid 事件可以使用原生的 Event Grid 架构或 CloudEvents v1.0 规范。使用 Event Grid 架构时，每个事件都包含 id（唯一标识符）、eventType（操作）、subject（支持筛选的分层路径）、eventTime (UTC)、data（负载）、dataVersion、metadataVersion 和 topic。CloudEvents 提供了一套标准化的属性，如 id、source、type、time、subject 和 data。选择 CloudEvents 可以简化跨平台的互操作性；Event Grid 架构则与源自 Azure 的事件保持一致，并支持对 subject 进行丰富的筛选。

事件订阅定义了路由、交付选项和筛选器。基本筛选器包括事件类型包含以及主题前缀/后缀 (subjectBeginsWith, subjectEndsWith)，这对于分层资源命名非常高效。高级筛选器可以匹配顶级事件或 data 内部的字段（例如，数值范围比较、字符串不区分大小写包含、布尔值等于以及数组包含）。您可以组合使用筛选器以实现精确的扇出控制，从而最大限度地减少下游工作和出口流量。

交付采用推送方式，具有至少一次语义。Event Grid 会使用指数退避策略进行重试。您可以配置最大重试次数和事件生存时间；当交付最终失败或事件过期时，Event Grid 可以将事件死信化，发送到您在订阅上指定的 Blob Storage 容器中。死信处理会保留负载和元数据，以供审计或重新处理；如果需要，可以使用一个单独的进程来重新激活并重放事件。Webhook 终结点会参与验证握手以证明所有权，对于受限网络，您可以优先选择托管的 Azure 终结点（Functions、Service Bus、Storage Queue），这些终结点无需公共暴露，并且可以使用 Azure AD 支持的授权。

Event Hubs：分区、使用者群组、吞吐量、捕获和可靠消费

Event Hubs 以低延迟引入大容量的遥测和日志流。数据被附加到分区中，分区是独立的、有序的提交日志。分区在创建时选定，以实现吞吐量并行化；生成者分配分区键以保持每个键的顺序，服务则将键哈希到分区。多个读取器可以并行处理分区；在单个分区内，顺序是有保证的。

使用者群组提供数据流的独立视图，允许不同的处理应用程序维护各自的位置而互不干扰（例如，一个实时异常检测器和一个存档管道）。水平扩展读取器需要进行分区所有权平衡；SDK 的 EventProcessorClient 负责协调实例之间的分区分配和重新平衡。

标准层的吞吐量单位 (TU) 定义了容量：每个 TU 享有一定的入口和出口带宽配额。自动扩充功能可以自动增加 TU 以应对峰值需求。高级版使用处理单元，提供专用的计算资源和可预测的延迟。监控限制指标以验证资源配置是否得当。Event Hubs 在同一端点上支持 Kafka 协议，从而简化了从 Kafka 客户端的直接迁移，无需运行代理 (broker)。

生成者可以使用 AMQP 或 HTTPS。AMQP（包括在 443 端口上运行的 AMQP-over-WebSockets）提供多路复用、持久连接和高效的批处理，推荐用于发送和接收。HTTPS 适用于简单或零星的发送，但不支持接收；它不提供长轮询功能，并且会牺牲效率和流控制。在受限的企业网络中，AMQP-over-WebSockets 在通过典型的出站代理时仍能保持性能。

检查点和偏移量管理对正确性至关重要。每个事件在每个分区中都有一个序列号和偏移量。接收者在数据流中前进，成功处理一批事件后，它们会将自己的位置设置检查点到持久存储中——通常是通过 EventProcessorClient 保存到 Azure Blob 存储容器。在重启或故障转移时，处理器会从最后一个检查点恢复，通过幂等处理程序实现至少一次的处理。如果没有检查点，使用者将从默认位置（最新或最早）开始，并有重复处理或跳过事件的风险。

捕获功能通过在可配置的时间或大小窗口内，自动将批处理的、仅追加的 Avro 文件写入 Azure Blob 存储或 Azure Data Lake Storage Gen2，从而提供服务器端存档。这消除了为冷路径分析创建自定义批处理器的需要，使下游工具（如 Spark、Synapse）能够使用相对于捕获管道具有精确一次语义的不可变流段。

Service Bus 与 Queue Storage：命令、工作流、会话和有害消息处理

Service Bus 是一个企业级消息代理，适用于需要丰富交付保证的命令、工作流和集成场景。队列实现点对点消息传递；每个消息由一个竞争性消费者接收。带有订阅的主题可实现发布/订阅模式：发布者发送到主题，独立的订阅根据规则接收副本。订阅规则可以是 SQL 筛选器、关联筛选器或布尔真值筛选器，它们计算每条消息是否应被包含，并可以通过操作添加或修改消息属性。

会话为相关消息提供有序、独占的处理。为属于同一组的消息（例如，订单 123 中的所有步骤）分配一个 SessionId。接收者接受会话锁，并按该会话的到达顺序处理消息，同时维护可选的会话状态，然后释放会话以允许下一个消费者获取所有权。这是大规模实现 FIFO 的首选模式。如果没有会话，无法保证跨竞争性消费者的顺序。

Service Bus 支持 PeekLock 和 ReceiveAndDelete 模式。PeekLock 是默认的可靠模式：消费者在锁定持续时间内锁定一条消息，处理它，然后通过 Complete 来结算它。如果处理失败，消费者可以 Abandon（使其再次可用）、Defer（通过序列号推迟到以后检索）或 Dead-letter（将其移动到实体独立的死信子队列，并附上原因和错误描述）。ReceiveAndDelete 通过在收到消息后立即删除它来换取吞吐量，牺牲了可靠性。

关键属性控制生命周期。生存时间（Time to Live, TTL）可以在实体级别设置默认值，并可被每条消息覆盖；过期的消息会根据配置被死信处理或丢弃。锁定持续时间控制消息为处理而被锁定的时长；SDK 可以在最大限制内为长时间工作自动续订锁。最大交付计数是按队列或订阅配置的；在达到那么多次交付尝试（Abandon 或锁丢失）后，消息会自动移动到死信队列（DLQ）。操作员会排空 DLQ 以进行诊断或使用修正逻辑进行重新处理。

Azure Queue Storage 是一个更简单、可大规模扩展的队列服务，提供 REST 接口，最适合基本的解耦、高扇出和成本敏感型工作负载。它提供至少一次交付、用于在处理期间隐藏消息的可见性超时，以及每条消息的 TTL（默认为 7 天，可配置，包括永不过期）。单个消息的大小受限，并且不提供会话、事务、顺序保证、重复检测、死信子队列和高级筛选器等功能。对于简单的后台工作和以低成本实现非常高的吞吐量，请选择 Queue Storage。当您需要复杂的路由（主题/订阅）、通过会话实现 FIFO、计划交付、延迟处理、跨实体的事务、重复检测窗口、AMQP 支持，或者当集成可靠性和治理至关重要时，请选择 Service Bus。一个常见的模式是通过 Event Grid 或 Queue Storage 扇入轻量级事件，并在 Service Bus 上协调业务关键型命令和状态转换。

Notification Hubs：推送路由和平台凭据管理

Notification Hubs 是一个跨平台推送引擎，可大规模管理设备注册，并将定向通知路由到 Apple (APNs)、Android (FCM)、Windows (WNS) 及其他平台。应用程序使用标签和标签表达式注册设备，从而实现精确的受众选择（例如，user:42 AND region:emea OR topic:promotions）。通过模板，您只需发送一个本地化的有效负载，平台特定的渲染器就会将其展开，这减少了服务器逻辑，并以最少的后端分支实现了按设备的个性化。安装模型将平台句柄、标签和模板封装在每个设备的单个资源中，从而简化了设备生命周期管理。

平台凭据管理是可靠交付的核心。对于 APNs，上传基于证书或基于令牌的凭据（包括密钥 ID、团队 ID 和 .p8 令牌），并为每个中心或命名空间选择沙盒或生产端点以隔离环境。对于 FCM，配置适当的服务器凭据（对于 HTTP v1，使用具有 OAuth2 范围的 Google 服务帐户）。对于 WNS，注册应用程序以获取包 SID 和客户端密码。凭据会定期轮换；请安排轮换并监控反馈渠道以发现无效的设备句柄。Notification Hubs 使用 SAS 对来自您的应用服务器的请求进行中心级身份验证，而 Azure AD 角色则保护管理操作。使用标签约定来分区多租户应用，并通过计划推送或批量推送来限制发送速率，以满足平台配额。

实际问题场景

星巴克正在推出一项全球移动点餐体验，该体验必须在订单准备好时通知顾客，可靠地处理咖啡师的工作流步骤，并分析设备遥测数据以进行主动维护。

使用 Event Grid 连接事件驱动的订单生命周期

创建一个自定义 Event Grid 主题 OrderEvents，并发布离散的领域事件，如 OrderPlaced、PaymentAuthorized 和 OrderReady。使用像 /stores/{storeId}/orders/{orderId} 这样的主题路径，以便按商店进行前缀筛选。配置订阅：一个订阅到 Service Bus 主题用于工作流处理，另一个订阅到 Azure Function 用于轻量级扩充。选择 Event Grid 是因为它具有低延迟扇出、模式规范化 (CloudEvents) 以及高效的筛选能力，可避免不必要的下游调用。

使用 Service Bus 主题和会话协调咖啡师工作流

定义一个 Service Bus 主题 Orders，并为每个处理阶段（Preparation、Handoff）设置订阅，每个订阅都带有基于 eventType 的关联或 SQL 筛选器。将命令作为消息发布，并设置 SessionId = {orderId}，以保证按订单的先进先出（FIFO）。消费者使用带自动续订锁的 PeekLock，并在成功时调用 Complete；在暂时性故障时，Abandon 会触发重试；在持久性故障或遇到死信消息时，达到最大传递计数后会将其移至死信队列（DLQ）以供后续检查。为特定阶段的消息设置 TTL（生存时间），可防止在商店关门后处理过时的工作。选择 Service Bus 是因为它能提供有序、可靠的命令处理、丰富的结算操作以及基于规则的发布/订阅。

使用 Event Hubs 引入并归档设备遥测数据

预配一个 Event Hub Telemetry，并设置足够的分区以按 deviceId 并行化处理，同时启用自动扩增 TU（吞吐量单位）以吸收峰值流量。设备网关通过 AMQP-over-WebSockets 发送数据，以高效地穿越公司代理。使用带有 Blob Storage 检查点设置的 EventProcessorClient，近乎实时地运行异常检测和警报。启用 Capture 功能将数据归档到 ADLS Gen2，形成不可变的 Avro 归档，以支持在 Synapse 中进行离线分析。选择 Event Hubs 是因为它能实现持续的高吞吐量引入，具有持久的偏移量和便捷的冷路径导出功能。

使用 Notification Hubs 定向推送通知

使用安装模型注册移动设备，为每个设备打上 user:{userId}、store:{storeId} 和平台标签。为 iOS 上传 APNs 令牌凭据，为 Android 上传 FCM 服务帐户；分离开发和生产中心以隔离凭据和反馈。当 OrderReady 事件到达时，Azure Function 会向 Notification Hubs 发送一个模板通知，该通知通过标签 user:{userId} AND store:{storeId} 定向到目标用户。选择 Notification Hubs 是因为它能提供平台无关的路由、标签表达式以及全球规模的集中式凭据管理。

确保可观察性和弹性

为 Event Grid 配置死信处理，将无法投递的事件保留到 Blob 容器中，以供审计和重放。监控 Service Bus 的死信队列（DLQ），并提供一个运维人员工作流来分类和重新入队已修正的消息。通过指标跟踪 Event Hubs 的消费者延迟，以验证检查点设置，并在积压增加时横向扩展处理器。这种组合提供了端到端的持久性：至少一次的交付，为异常情况提供重放路径，同时保持正常路径的快速和成本效益。

该架构清晰地分离了关注点：Event Grid 驱动响应式编排，Service Bus 保证工作流的正确性和顺序，Event Hubs 处理大规模的连续遥测数据，而 Notification Hubs 则以最少的后端复杂性提供精确的、特定于平台的客户通知。

← Azure API 管理 · 所有领域 · Azure 缓存、CDN 与性能 →

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