.Net Core API中使用ServiceBusClient.CreateReceiver是否符合服务总线最佳实践？

方案合理性评估 #

你的核心架构选型逻辑完全合理，用Azure Service Bus解耦老旧Webforms系统和新云原生应用的同步需求，避免在维护性差的老系统上改造新增API调用逻辑，既降低了老系统的改造成本和风险，也天然具备了消息持久化、削峰填谷、异步解耦的优势，核心架构方向是正确的。

现有实现的潜在问题 #

• 递归调用风险：ReceiveMessagesAsync和Listen方法互相递归调用且无退出机制，长时间运行后会触发栈溢出，导致进程异常崩溃。
• 资源浪费：每次调用Listen方法都会新建一个ServiceBusReceiver实例，而Service Bus的客户端、接收器实例设计为可长期复用，频繁创建销毁会额外消耗连接资源，甚至触发Azure Service Bus的连接数限流规则。
• 异常处理不完善：当前仅做了捕获后直接重启的逻辑，没有异常日志、没有重试退避策略，如果遇到持续故障（比如网络断连、队列权限错误）会导致进程无限快速重试，消耗大量CPU资源，且故障原因无法排查。
• 后台任务托管方式不规范：在Startup中直接用Task.Run启动长期运行的任务，没有和ASP.NET Core的应用生命周期绑定，当应用池回收、服务正常停止时，无法收到停止信号，会导致处理中的消息被强制中断，出现消息丢失、重复处理的问题。
• 拉取逻辑效率低：自己实现的单条拉取逻辑吞吐量上限很低，当同步数据量上涨时无法快速处理积压消息，也没有内置的锁续期能力，如果单条消息处理时间超过队列设置的锁时长，会导致消息被其他接收器重复拉取。

优化方案 #

建议直接使用Azure.Messaging.ServiceBus SDK内置的ServiceBusProcessor组件配合ASP.NET Core官方的BackgroundService来实现监听逻辑，这两类组件已经内置了并发控制、自动锁续期、异常退避、优雅启停等能力，不需要自己手动实现拉取逻辑：

优化后的消息接收器实现

public class ServiceBusBackgroundService : BackgroundService
{
    private readonly IConfiguration _configuration;
    private readonly IServiceBusMessageHandlerService _handlerService;
    private readonly ILogger<ServiceBusBackgroundService> _logger;
    private ServiceBusClient _serviceBusClient;
    private ServiceBusProcessor _processor;

    public ServiceBusBackgroundService(IConfiguration configuration, 
        IServiceBusMessageHandlerService handlerService,
        ILogger<ServiceBusBackgroundService> logger)
    {
        _configuration = configuration;
        _handlerService = handlerService;
        _logger = logger;
    }

    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        _serviceBusClient = new ServiceBusClient(_configuration.GetConnectionString("ServiceBusUrl"));
        _processor = _serviceBusClient.CreateProcessor(_configuration.GetConnectionString("ServiceBusQueue"), new ServiceBusProcessorOptions
        {
            // 可根据你的处理能力调整并发数
            MaxConcurrentCalls = 5,
            AutoCompleteMessages = false,
            // 自动续期消息锁，避免长耗时处理导致锁过期
            MaxAutoLockRenewalDuration = TimeSpan.FromMinutes(5)
        });

        _processor.ProcessMessageAsync += ProcessMessageAsync;
        _processor.ProcessErrorAsync += ProcessErrorAsync;

        await _processor.StartProcessingAsync(stoppingToken);
        await Task.Delay(Timeout.Infinite, stoppingToken);
    }

    private async Task ProcessMessageAsync(ProcessMessageEventArgs args)
    {
        try
        {
            await _handlerService.DelegateMessage(new List<ServiceBusReceivedMessage> { args.Message }, args);
            await args.CompleteMessageAsync(args.Message);
        }
        catch (Exception ex)
        {
            _logger.LogError(ex, "处理消息失败，消息将移入死信队列");
            await args.DeadLetterMessageAsync(args.Message);
        }
    }

    private Task ProcessErrorAsync(ProcessErrorEventArgs args)
    {
        _logger.LogError(args.Exception, "Service Bus处理器出现错误，错误源：{ErrorSource}", args.ErrorSource);
        // 内置会自动退避重试，不需要手动重启
        return Task.CompletedTask;
    }

    public override async Task StopAsync(CancellationToken cancellationToken)
    {
        if (_processor != null)
        {
            await _processor.StopProcessingAsync(cancellationToken);
            await _processor.DisposeAsync();
        }
        if (_serviceBusClient != null)
        {
            await _serviceBusClient.DisposeAsync();
        }
        await base.StopAsync(cancellationToken);
    }
}

服务注册

在Program.cs（.NET 6+）或者Startup.cs中注册即可，不需要手动启动：

services.AddHostedService<ServiceBusBackgroundService>();

优化后不需要额外开发控制器接口做重启能力，ServiceBusProcessor内置了故障自动重试恢复的能力。

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