Azure Fundamentals · 课时

使用 Azure Service Bus 实现解耦消息传递

Q: 「使用 Azure Service Bus 实现解耦消息传递」这节课中我会学到什么？

创建包含队列和主题的 Service Bus 命名空间，从应用发送和接收消息，并配置死信队列来处理失败的消息。 你通过在浏览器中直接运行的动手代码来练习 Azure Fundamentals，全天候 AI 导师会在你学习这节课的过程中回答你的问题。

创建包含队列和主题的 Service Bus 命名空间，从应用发送和接收消息，并配置死信队列来处理失败的消息。

使用 Azure Service Bus 实现解耦消息传递 是 CoddyKit 上的免费 Azure Fundamentals 课时。这是第 2 节课，共 4 节。你可以在下方免费阅读本课时的完整内容 — 然后在浏览器中使用内置代码编辑器和全天候 AI 导师进行实践。这是 Azure Fundamentals 学习路径的一部分，你的进度在网页和 CoddyKit 应用中同步。 Azure Fundamentals 课程共包含 4 节课。

为什么要通过消息传递实现解耦？

在紧耦合架构中，服务会以同步方式相互调用——如果下游服务响应缓慢或发生故障，调用方也会被阻塞或失败。消息队列在生产者和消费者之间引入异步缓冲区，因此下游服务变慢时，不会导致故障向上游级联。Azure Service Bus 是 Microsoft 面向企业的消息传递服务，提供队列（点对点）和主题（发布-订阅），并支持可靠传递、排序和死信处理。

Service Bus 命名空间和层级

Service Bus 命名空间是所有消息传递实体（队列和主题）的顶级容器，并提供 FQDN 终结点（例如 myns.servicebus.windows.net）。命名空间分为三个层级：Basic（仅支持队列，不支持主题，消息大小最大为 256 KB）、Standard（支持队列和主题，最大 256 KB）以及 Premium（支持队列和主题，消息大小最大为 100 MB，并提供专用容量、VNet 集成和地域灾难恢复）。对于需要 SLA 支持性能的生产工作负载，必须使用 Premium。

# Create a Service Bus namespace (Standard tier)
az servicebus namespace create \
  --resource-group myRG \
  --name myservicebusns \
  --location eastus \
  --sku Standard

队列：点对点消息传递

Service Bus 队列按照 FIFO 顺序存储消息，并将每条消息准确传递给一个消费者。消费者使用查看并锁定机制接收消息：消息在处理期间会暂时对其他消费者隐藏。如果消费者成功完成处理，就会调用 CompleteMessage() 将消息从队列中删除。如果处理失败，消费者会调用 AbandonMessage()，消息将再次变为可见，以便重试。经过可配置次数的传递尝试后，无法处理的消息会被移至死信队列（DLQ）。

# Create a Service Bus queue with DLQ enabled
az servicebus queue create \
  --resource-group myRG \
  --namespace-name myservicebusns \
  --name orders \
  --max-delivery-count 5 \
  --default-message-time-to-live P7D \
  --dead-lettering-on-message-expiration true

主题和订阅

主题实现发布-订阅模式：生产者向主题发送消息，该主题上的任意数量的订阅都会分别收到一份消息副本。订阅可以配置筛选器（SQL 或关联表达式），以便只接收消息的一个子集——例如，HighPriority 订阅只接收 Priority 属性等于 High 的消息。这样，单个主题就可以将消息分发给多个下游服务，而每个服务只关注不同的事件子集。

# Create a topic and two subscriptions with filters
az servicebus topic create \
  --resource-group myRG \
  --namespace-name myservicebusns \
  --name order-events

az servicebus topic subscription create \
  --resource-group myRG \
  --namespace-name myservicebusns \
  --topic-name order-events \
  --name high-priority-sub

az servicebus topic subscription rule create \
  --resource-group myRG \
  --namespace-name myservicebusns \
  --topic-name order-events \
  --subscription-name high-priority-sub \
  --name PriorityFilter \
  --filter-sql-expression 'Priority = '"'"'High'"'"''

发送和接收消息

Azure Service Bus SDK 提供用于发送和接收消息的 ServiceBusClient。要发送消息，请创建 ServiceBusSender 并调用 SendMessageAsync()。要接收消息，请创建 ServiceBusReceiver 并调用 ReceiveMessageAsync()（基于拉取），或者使用带有事件处理程序的 ServiceBusProcessor进行基于推送的持续处理。在 Service Bus SDK 中使用 DefaultAzureCredential 可以免除连接字符串的需要，从而保持无密码模式。

# Python: Send a message to a Service Bus queue
from azure.servicebus import ServiceBusClient, ServiceBusMessage
from azure.identity import DefaultAzureCredential

credential = DefaultAzureCredential()
client = ServiceBusClient(
  fully_qualified_namespace='myservicebusns.servicebus.windows.net',
  credential=credential
)
with client.get_queue_sender(queue_name='orders') as sender:
    msg = ServiceBusMessage('{ 'orderId': '12345', 'amount': 99.99 }')
    sender.send_messages(msg)
    print('Message sent')

死信队列

死信队列（DLQ）是一个会自动接收无法传递消息的子队列。出现以下情况时，消息会进入死信队列：超过最大传递次数、过期（TTL 已到期），或未通过主题订阅筛选器的评估。监控 DLQ 至关重要——不断增长的 DLQ 表明存在系统性的处理故障。DLQ 中的消息会保留其原始内容，同时包含 Service Bus 添加的死信原因和说明属性，以帮助诊断根本原因。

# Read messages from the dead-letter queue
az servicebus queue show \
  --resource-group myRG \
  --namespace-name myservicebusns \
  --name 'orders/$DeadLetterQueue' \
  --query 'countDetails.deadLetterMessageCount'

用于排序的消息会话

会话可以对属于同一逻辑组的消息启用严格排序。每条消息都会标记一个 SessionId（例如客户 ID 或订单 ID），而支持会话的消费者会独占式地按照 FIFO 顺序接收给定会话中的所有消息。对于必须按顺序执行各个步骤的工作流，会话至关重要——例如处理特定订单的所有事件：Created → PaymentReceived → Shipped → Delivered。必须在创建队列或订阅时启用会话。

Service Bus、Event Grid 与 Event Hubs 的比较

这三种 Azure 消息传递服务经常被混淆：Service Bus用于可靠的事务型企业消息传递，支持排序、会话和 DLQ，适合订单处理、金融交易和工作流编排。Event Grid用于反应式事件路由（例如 Blob 已上传或 VM 已删除），可以将事件分发给多个处理程序，但不支持排序或重放。Event Hubs用于高吞吐量事件流处理（每秒数百万个事件），支持重放，适合 IoT 遥测和日志引入。请根据排序、吞吐量和持久性要求进行选择。

地域灾难恢复

Service Bus 地域灾难恢复（Geo-DR）会将命名空间元数据（队列、主题、订阅和访问策略）复制到次要区域。配对区域共享一个别名主机名；如果主要区域发生故障，您可以启动故障转移，别名将解析到次要区域。请注意，在 Standard 层中，消息数据（正在传输中的消息）不会被复制——只有 Premium 层的 Geo-DR 会复制消息。对于任务关键型消息传递，请使用 Premium + Geo-DR 以满足 RTO 和 RPO 要求。

扩展和分区实体

对于高吞吐量场景，请在创建队列和主题时启用分区。分区实体在内部使用多个消息代理和存储片段，从而提高吞吐量容量。Standard 层中的分区实体总大小最高为 80 GB。每条消息都会根据其 PartitionKey 属性路由到某个分区（如果启用了会话，则默认为会话 ID）。分区是创建时的一次性决定——无法为现有队列启用分区。若要在不引入分区复杂性的情况下获得最高的有保障吞吐量，请使用 Premium 层。

# Create a partitioned queue (Standard tier)
az servicebus queue create \
  --resource-group myRG \
  --namespace-name myservicebusns \
  --name orders-partitioned \
  --enable-partitioning true

监控 Service Bus 运行状况

需要在 Azure Monitor 中监控的关键 Service Bus 指标包括：Active Messages（队列深度——深度上升表示消费者处理滞后）、Dead-lettered Messages（处理失败）、Server Errors 和 User Errors（身份验证和限制问题），以及 Incoming Requests（总体吞吐量）。请配置指标警报，以便在死信队列增长超过阈值，或活动消息在持续一段时间内未被消费时通知运维团队。

快速检查

测试您对本课中 Microsoft Azure Fundamentals (AZ-900) 概念的理解。

课程回顾

在本课中，您学习了：Service Bus 队列通过查看并锁定传递机制提供点对点消息传递，并通过死信队列处理失败的消息；主题和订阅通过筛选规则将消息分发给多个消费者；会话则可以按顺序处理属于同一逻辑组的消息。接下来，我们将探索 Azure Container Apps，了解如何部署现代微服务。

常见问题解答

「使用 Azure Service Bus 实现解耦消息传递」课时是免费的吗？

是的 — 「使用 Azure Service Bus 实现解耦消息传递」的完整文本可在网页上免费阅读。要进行交互式练习（内置代码编辑器和全天候 AI 导师）并解锁 Azure Fundamentals 课程的其余内容，请升级到 CoddyKit PRO。 Azure Fundamentals 课程共包含 4 节课。

「使用 Azure Service Bus 实现解耦消息传递」这节课中我会学到什么？

创建包含队列和主题的 Service Bus 命名空间，从应用发送和接收消息，并配置死信队列来处理失败的消息。你通过在浏览器中直接运行的动手代码来练习 Azure Fundamentals，全天候 AI 导师会在你学习这节课的过程中回答你的问题。

学习 Azure Fundamentals 需要有经验吗？

无需任何先前经验。CoddyKit 上的 Azure Fundamentals 课程适合初学者到高级学习者，你可以从这里开始或从头开始，按照自己的节奏学习。这是第 2 节课，共 4 节。

「使用 Azure Service Bus 实现解耦消息传递」课时需要多长时间？

大多数 CoddyKit 课程大约需要 5–10 分钟。每节课都很精短且互动，所以你能稳步进步，并在网页和应用中从离开的地方继续。

我能在这节 Azure Fundamentals 课中编写并运行代码吗？

能。每节 Azure Fundamentals 课都包含内置代码编辑器，你可以在浏览器中直接编写并运行真实代码，并获得即时 AI 反馈 — 无需本地设置。

此课程中的所有课时

← 返回 Azure Fundamentals