MassTransit中Scoped Filters与RoutingKeyFormatter的执行顺序问题解析

问题背景

在使用MassTransit 8.x版本与RabbitMQ集成时，开发者可能会遇到一个微妙但重要的问题：当从8.2.0升级到8.2.1或更高版本后，消费者突然停止接收消息。这个问题源于MassTransit内部处理消息时Scoped Filters和RoutingKeyFormatter执行顺序的变化。

技术细节

在MassTransit的消息处理流程中，有两个关键组件会影响消息的路由：

1. Scoped Filters：用于在消息处理管道中添加自定义逻辑，通常与特定消息类型关联
2. RoutingKeyFormatter：负责为消息生成路由键，直接影响消息如何被路由到队列

在8.2.0版本中，Scoped Filters会在拓扑约定(topology conventions)应用之前执行。这意味着开发者可以在Filter中修改消息属性，这些修改会反映在最终的路由键中。然而从8.2.1版本开始，执行顺序发生了变化，RoutingKeyFormatter现在会在Scoped Filters之前执行。

问题表现

当开发者依赖Scoped Filters来设置或修改消息属性（这些属性随后用于生成路由键）时，升级后会出现消费者无法接收消息的情况。这是因为：

1. RoutingKeyFormatter先执行，使用原始消息属性生成路由键
2. 随后Scoped Filters执行，修改消息属性
3. 但此时路由键已经确定，修改不会影响已生成的路由键
4. 消费者订阅的是基于修改后属性预期的路由键，导致不匹配

解决方案

针对这个问题，MassTransit团队建议的解决方案是将路由键相关的逻辑直接移到RoutingKeyFormatter中，而不是依赖Scoped Filters来设置相关属性。这样做有几个优点：

1. 逻辑更加明确和直接
2. 不再依赖执行顺序
3. 代码更加健壮，不易受内部实现变化影响

具体实现方式是在配置发送端点时直接定义RoutingKeyFormatter：

configurator.Send<TEvent>(x =>
{
    x.UseRoutingKeyFormatter(context =>
    {
        var durableEventName = context.Message.GetType()
            .GetProperty("DurableEventName")?
            .GetValue(context.Message) 
            ?? throw new InvalidOperationException("缺少必要属性");
        
        return (string)durableEventName;
    });
});

版本兼容性考量

这个问题凸显了在补丁版本升级时可能遇到的兼容性问题。虽然按照语义化版本控制原则，补丁版本不应包含破坏性变更，但某些内部实现的调整仍可能影响特定使用场景。因此建议：

1. 在测试环境中充分验证补丁版本升级
2. 关注框架的变更日志
3. 避免过度依赖框架内部执行顺序

最佳实践

基于这个案例，可以总结出一些MassTransit使用的最佳实践：

1. 路由逻辑集中化：将与路由相关的逻辑集中放在RoutingKeyFormatter中
2. 减少执行顺序依赖：避免编写依赖内部组件执行顺序的代码
3. 明确职责分离：Scoped Filters更适合处理横切关注点，而非影响路由的核心属性
4. 升级策略：即使是补丁版本升级，也应进行适当的回归测试

总结

MassTransit 8.2.1版本对内部执行顺序的调整虽然微小，但对特定使用场景产生了影响。通过理解框架内部工作原理和采用推荐的最佳实践，开发者可以构建更加健壮和可靠的消息处理系统。这个案例也提醒我们，在分布式系统开发中，明确组件职责和减少隐式依赖的重要性。