ASP.NET Core基于MassTransit的Azure Service Bus请求响应超时问题

核心问题根源 #

你目前的代码存在两个致命问题，导致请求消息根本无法到达Worker，消费者自然不会触发，最终超时：

1. Worker端仅注册了Consumer但未绑定到接收端点：MassTransit要求必须显式为Consumer配置监听的接收端点，否则总线启动时不会创建、也不会监听对应队列，完全不会消费消息。
2. WebAPI与Worker的消息路由未对齐：Azure Service Bus的队列是点对点模式，请求消息必须发送到Worker正在监听的队列地址，你当前没有指定路由规则，消息会被发送到MassTransit默认生成的地址，和Worker监听的队列不匹配。

修复步骤 #

第一步：修复Worker端的Consumer绑定配置

在Worker的UsingAzureServiceBus回调中新增接收端点配置，指定自定义队列名并绑定Consumer，修改后的Startup核心配置如下：

public void ConfigureServices(IServiceCollection services)
{
    services.AddControllers();
    services.AddMassTransit(massTransitConfig =>
    {
        // 先注册Consumer
        massTransitConfig.AddConsumer<CreateScheduleRequestClient>();
        
        massTransitConfig.UsingAzureServiceBus((ctx, cfg) =>
        {
            cfg.Host("Endpoint=sb://----.servicebus.windows.net/;SharedAccessKeyName=RootManageSharedAccessKey;SharedAccessKey=----");
            
            // 新增：配置接收端点，指定唯一队列名，绑定对应Consumer
            cfg.ReceiveEndpoint("create-schedule-worker-queue", e =>
            {
                e.ConfigureConsumer<CreateScheduleRequestClient>(ctx);
            });
        });
    });
    // 其他服务配置保持不变
}

注意：队列名可以自定义，只要在当前Azure Service Bus命名空间下唯一即可，MassTransit会自动创建该队列。

第二步：对齐WebAPI端的请求路由

WebAPI端的请求客户端需要显式指定将请求消息发送到Worker监听的队列地址，修改WebAPI的MassTransit配置如下：

public void ConfigureServices(IServiceCollection services)
{
    services.AddControllers();
    services.AddMassTransit(massTransitConfig =>
    {
        massTransitConfig.UsingAzureServiceBus((ctx, cfg) =>
        {
            cfg.Host("Endpoint=sb://----.servicebus.windows.net/;SharedAccessKeyName=RootManageSharedAccessKey;SharedAccessKey=----");
        });
        
        // 新增：注册请求客户端，显式指定请求发送的队列地址（和Worker端的队列名完全一致）
        massTransitConfig.AddRequestClient<CreateScheduleRequest>(new Uri("queue:create-schedule-worker-queue"));
    });
    // 其他服务配置保持不变
}

第三步：修复响应DTO的序列化兼容性问题

MassTransit默认使用的序列化器要求DTO必须包含无参构造（用于跨应用反序列化），你当前的ScheduleCreatedResponse仅带参构造，后续即使消息路由打通，响应也会因为序列化失败导致超时，修改后的DTO如下：

public class ScheduleCreatedResponse
{
    // 改为可读写属性，新增无参构造，保留原带参构造
    public bool Succeeded { get; set; }

    public ScheduleCreatedResponse() {}
    public ScheduleCreatedResponse(bool succeeded)
    {
        Succeeded = succeeded;
    }
}

第四步：（可选优化）简化Controller的依赖注入

完成请求客户端注册后，不需要再注入IBus，直接注入预注册的IRequestClient即可，修改后的Controller代码如下：

[Route("api/requests")]
public class RequestsController : ControllerBase
{
    private readonly IRequestClient<CreateScheduleRequest> _requestClient;

    // 直接注入预注册的请求客户端
    public RequestsController(IRequestClient<CreateScheduleRequest> requestClient)
    {
        _requestClient = requestClient;
    }

    [HttpPost("create-schedule")]
    public async Task<IActionResult> CreateSchedule()
    {
        var response = await _requestClient.GetResponse<ScheduleCreatedResponse>(new CreateScheduleRequest());
        return Ok(response.Message.Succeeded);
    }
}

验证方式 #

1. 先启动Worker应用，确保MassTransit初始化完成，队列创建成功
2. 再调用WebAPI的POST /api/requests/create-schedule接口，此时会正常触发Worker的消费者逻辑，返回响应

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