如何配置Azure Function仅在Service Bus队列A的DLQ收到消息时触发

1. 如何配置Azure Function仅在队列A的DLQ收到消息时触发？ #

有两种主流实现方案：

方案一：直接用Service Bus队列触发器监听DLQ #

每个Service Bus队列的死信队列（DLQ）有固定命名规则：<原队列名>/$DeadLetterQueue，队列A的DLQ名称为A/$DeadLetterQueue。直接在.NET Function中配置触发器指向该DLQ即可：

using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.Logging;

namespace DLQNotificationFunction
{
    public class DLQTriggerFunction
    {
        private readonly ILogger<DLQTriggerFunction> _logger;

        public DLQTriggerFunction(ILogger<DLQTriggerFunction> logger)
        {
            _logger = logger;
        }

        [Function("DLQTriggerFunction")]
        public void Run(
            [ServiceBusTrigger("A/$DeadLetterQueue", Connection = "ServiceBusConnectionString")] string messageBody)
        {
            _logger.LogInformation("收到队列A的DLQ消息: {Message}", messageBody);
            // 执行调用API通知用户故障的业务逻辑
        }
    }
}

注意：需确保Service Bus命名空间SKU为Standard或Premium，Basic SKU不支持完整的DLQ监听能力，也无法启用Event Grid集成。

方案二：通过Event Grid推送DLQ事件到Function #

当队列A的DLQ收到消息时，Service Bus会向Event Grid发送事件，可配置订阅将事件推送到Function：

1. 确认Service Bus命名空间已启用Event Grid集成（Standard/Premium SKU默认支持）；
2. 创建Event Grid系统主题，关联目标Service Bus命名空间；
3. 配置Event Grid订阅，筛选队列A的DLQ事件，将事件发送到Function的Event Grid触发器端点。

2. 使用Terraform搭建该事件驱动架构的最佳实践 #

（1）模块化复用资源配置 #

将重复的Service Bus队列配置抽成Terraform模块，避免代码冗余。例如创建servicebus_queue模块：

# modules/servicebus_queue/main.tf
resource "azurerm_servicebus_queue" "queue" {
  name         = var.queue_name
  namespace_id = var.namespace_id

  # Basic SKU不支持分区，仅prod环境启用
  partitioning_enabled         = var.environment == "prod"
  batched_operations_enabled   = true
  requires_session             = false
  requires_duplicate_detection = var.environment == "prod"

  lock_duration                           = "PT1M"
  duplicate_detection_history_time_window = "PT10M"
  max_delivery_count                      = 3
  dead_lettering_on_max_delivery_count    = true
  dead_lettering_on_message_expiration    = true
}

根模块中调用：

module "queue_a" {
  source       = "./modules/servicebus_queue"
  queue_name   = "A"
  namespace_id = azurerm_servicebus_namespace.servicebus_namespace.id
  environment  = var.environment
}

module "queue_b" {
  source       = "./modules/servicebus_queue"
  queue_name   = "B"
  namespace_id = azurerm_servicebus_namespace.servicebus_namespace.id
  environment  = var.environment
}

module "queue_c" {
  source       = "./modules/servicebus_queue"
  queue_name   = "C"
  namespace_id = azurerm_servicebus_namespace.servicebus_namespace.id
  environment  = var.environment
}

（2）配置最小权限原则 #

为Azure Function分配队列A的DLQ监听权限，使用Terraform创建授权规则并绑定到Function的托管标识：

# 为队列A的DLQ创建监听权限授权规则
resource "azurerm_servicebus_queue_authorization_rule" "queue_a_dlq_listen" {
  name                = "dlq-listen"
  namespace_id        = azurerm_servicebus_namespace.servicebus_namespace.id
  queue_name          = "A/$DeadLetterQueue"
  listen              = true
  send                = false
  manage              = false
}

# 将权限分配给Function的系统托管标识
resource "azurerm_role_assignment" "function_sb_listen" {
  scope                = azurerm_servicebus_queue_authorization_rule.queue_a_dlq_listen.id
  role_definition_name = "Azure Service Bus Data Receiver"
  principal_id         = azurerm_function_app.dlq_notification_function.identity[0].principal_id
}

（3）统一状态与标签管理 #

• 使用Azure Blob存储作为Terraform状态后端，避免本地状态文件的协作冲突；
• 通过local变量定义通用标签，合并资源专属标签实现统一管理：

locals {
  azure_common_tags = {
    environment = var.environment
    project     = "bwp"
  }
}

resource "azurerm_servicebus_namespace" "servicebus_namespace" {
  # ... 原有配置
  tags = merge(local.azure_common_tags, {
    service = "network",
    team    = "backend"
  })
}

（4）启用DLQ核心配置 #

修正原队列配置，开启死信规则确保消息能进入DLQ：

resource "azurerm_servicebus_queue" "shared_servicebus_queue_a" {
  # ... 原有配置
  max_delivery_count                      = 3
  dead_lettering_on_max_delivery_count    = true
  dead_lettering_on_message_expiration    = true
}

3. 应使用Event Grid订阅还是有更优的DLQ触发方案？ #

两种方案各有适用场景，需根据需求选择：

Service Bus队列触发器（直接监听DLQ） #

• 优势：配置简单，无需额外资源；内置重试机制，处理失败的消息自动重新入队；
• 劣势：基于轮询机制，存在一定延迟（默认轮询间隔30秒，可调整）；仅支持Standard/Premium SKU；
• 适用场景：对实时性要求不高的故障通知场景，快速搭建的小型系统。

Event Grid订阅推送事件 #

• 优势：事件实时推送，延迟极低；支持丰富的事件过滤逻辑；可扩展到其他事件消费端（如Logic Apps、Web Apps）；
• 劣势：配置步骤较多，需创建Event Grid主题和订阅；依赖Service Bus的Standard/Premium SKU；
• 适用场景：对实时性要求高的故障响应场景，需要整合多系统事件的架构。

补充：若使用Basic SKU的Service Bus，只能选择直接监听DLQ的方式，但需注意Basic SKU的DLQ功能限制（如不支持会话、分区的DLQ处理）。

4. 如何确保队列B、C的消息不会触发该函数？ #

从两个层面保障隔离：

（1）触发器目标精准定位 #

• 使用Service Bus触发器时，明确指定监听队列A的DLQ（A/$DeadLetterQueue），队列B、C的DLQ命名不同，自然不会触发；
• 使用Event Grid订阅时，添加筛选条件仅接收队列A的DLQ事件：

resource "azurerm_eventgrid_system_topic_event_subscription" "sb_dlq_subscription" {
  name                   = "queue-a-dlq-subscription"
  system_topic_id        = azurerm_eventgrid_system_topic.sb_topic.id
  endpoint_type          = "AzureFunction"
  azure_function_endpoint {
    function_id = azurerm_function_app.dlq_notification_function.id
  }

  filter {
    included_event_types = ["Microsoft.ServiceBus.DeadletterMessagesAvailable"]
    subject_begins_with  = "/namespaces/${azurerm_servicebus_namespace.servicebus_namespace.name}/queues/A/messages/DeadLetterQueue"
  }
}

（2）权限隔离 #

仅为Azure Function分配队列A的DLQ监听权限，不授予队列B、C的任何权限。即使出现配置错误，Function也无法访问B、C的DLQ，避免误触发。

内容的提问来源于stack exchange，提问作者Tiago Ferreira