Azure Service Bus订阅启停后消息投递计数未递增问题及替代方案咨询

根据你描述的工作流和问题现象，确实是使用Microsoft.Azure.Management.ServiceBus包的CreateOrUpdate方法修改订阅状态时，会重置消息的投递计数（Delivery Count）——因为这个操作本质是覆盖订阅的全部属性，包括内部维护的消息重试状态。下面是几个不需要依赖Management包的替代方案，能避免投递计数被重置：

1. 使用Azure Service Bus Administration SDK（推荐） #

最新的Azure.Messaging.ServiceBus包提供了ServiceBusAdministrationClient，可以直接修改订阅的运行时状态，且不会触动消息的投递计数。这个SDK专门用于管理Service Bus实体的运行时属性，比Management包更轻量且针对性更强。

示例代码（禁用/启用订阅） #

using Azure.Messaging.ServiceBus.Administration;

// 初始化Administration客户端
var adminClient = new ServiceBusAdministrationClient("<你的Service Bus连接字符串>");
var topicName = "Notifications";
var subscriptionName = "<目标订阅名>";

// 禁用订阅
var subscriptionProps = await adminClient.GetSubscriptionAsync(topicName, subscriptionName);
subscriptionProps.Status = EntityStatus.Disabled;
await adminClient.UpdateSubscriptionAsync(subscriptionProps);

// 启用订阅（恢复时）
subscriptionProps.Status = EntityStatus.Active;
await adminClient.UpdateSubscriptionAsync(subscriptionProps);

这个方法仅更新订阅的Status属性，不会重置任何消息级别的计数状态，完全符合你的需求。

2. 改用延迟重试策略替代订阅禁用 #

如果业务允许，你可以跳过禁用订阅的操作，转而在消息投递失败时将消息延迟（Defer），同时通过健康检查Function监控目标服务状态。当服务恢复后，再主动接收延迟的消息进行重试：

示例代码（延迟消息） #

在你的Function投递失败时，替换抛异常+禁用订阅的逻辑：

// 投递失败时，延迟消息（比如延迟30分钟）
var deferUntil = DateTimeOffset.UtcNow.AddMinutes(30);
await serviceBusMessage.DeferAsync(deferUntil);

然后在健康检查Function中，当服务恢复后，使用ReceiveDeferredMessageAsync来获取并处理延迟的消息：

var subscriptionClient = new ServiceBusClient("<连接字符串>").CreateSubscriptionClient(topicName, subscriptionName);
var deferredMessageIds = await subscriptionClient.PeekDeferredMessageIdsAsync();
foreach (var messageId in deferredMessageIds)
{
    var deferredMessage = await subscriptionClient.ReceiveDeferredMessageAsync(messageId);
    // 重新投递逻辑...
}

这种方式完全不需要修改订阅状态，自然不会影响投递计数，还能更精细地控制重试时机。

3. 调整现有Switcher服务的实现 #

你的代码中调用了ServiceBusTopicSubscriptionSwitcherUri服务来修改订阅状态，需要将这个服务的实现从Microsoft.Azure.Management.ServiceBus包切换到上面提到的Azure.Messaging.ServiceBus.Administration包。这样整个工作流就能避免重置投递计数。

关键原理说明 #

Microsoft.Azure.Management.ServiceBus的CreateOrUpdate是面向资源管理的API（比如创建/删除订阅），它会重新同步订阅的所有属性，包括内部的计数器状态；而Azure.Messaging.ServiceBus.Administration的UpdateSubscription是面向运行时状态的API，仅修改指定的属性（如Status），不会干扰消息的投递计数等业务状态。

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