使用MassTransit向Azure Service Bus发布消息出现间歇性缓慢问题

配置类排查 #

• 核对MassTransit的Azure Service Bus客户端配置，重点检查MessageSender池化策略、重试退避规则。7.1.8版本默认的重试策略如果开启了指数退避，遇到ASB服务端瞬时错误时的等待时长刚好会出现10秒、30秒这类固定阈值的延迟，和你观测到的现象完全吻合。
• 检查ASB命名空间的吞吐量配额：Premium级实例每个消息单元的入站/出站阈值为1000条/秒或1MB/秒，瞬时流量超过配额时ASB会返回429节流状态码，客户端默认会自动等待重试，该等待时长也会表现为固定的10秒级延迟。

代码与逻辑排查 #

• 调整当前Publish调用的代码写法：你当前使用Select生成Publish任务列表属于惰性求值，多次枚举会触发重复的Publish调用，建议改为主动求值：

var tasks = updatedItems.Select(x => bus.Publish<ISomeEvent>(new SomeEvent(x, x.Parameters))).ToList();

• 确认事件拓扑的自动创建逻辑：MassTransit首次发布某类事件时会自动创建对应的Topic，如果你服务启动后是批量发布事件，或者Topic配置有变更，首次的拓扑检查操作会产生额外耗时。

日志与指标排查 #

• 开启MassTransit Debug级日志和Azure Service Bus SDK日志，定位Publish调用到SEND日志输出之间的耗时阶段：确认是卡在拓扑检查、消息序列化，还是ASB服务端的请求响应环节。
• 到Azure Portal查看对应时间窗口的ASB指标，重点关注「节流请求数」「服务端延迟」「当前连接数」三个维度：你观测的CPU、内存属于实例级指标，连接数打满、瞬时节流这类命名空间级别的异常不会触发实例告警。
• 抓取对应时间点的网络包，排查是否存在TCP重连、TLS握手超时的网络层问题。

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