如何对基于RabbitMQ binder的Spring Cloud Stream开展性能测试

1. 无侵入式压测工具方案 #

这类方案不需要修改现有业务服务代码，适配成本低，适合快速做性能验证：

• JMeter 搭配 RabbitMQ 插件
  行业最常用的压测方案，直接安装JMeter的RabbitMQ Producer插件，配置对应Exchange、路由键、连接信息后，就可以自定义并发数、消息大小、发送速率向目标队列生产测试消息。
  核心观测维度：消费端TPS（每秒处理消息数）、端到端消息延迟（可在消息头加send_time字段计算收发时间差）、消息堆积速率、服务节点CPU/内存/网络占用、RabbitMQ服务端队列长度、落盘耗时等指标。可以逐一调整prefetch count、消费线程数、消息持久化配置等参数，定位不同场景下的性能瓶颈。
• Gatling 自定义RabbitMQ生产逻辑
  适合需要更高并发压测、定制化压测流程的场景，Gatling基于Scala开发，并发性能优于JMeter，只需要写少量自定义代码实现RabbitMQ消息生产逻辑，就可以灵活控制消息生成规则、发送速率曲线，测试结束后会自动生成可视化的性能报告，适合需要长期做性能回归测试的项目。

2. 代码层内置压测方案 #

这类方案和生产环境的实际运行逻辑完全一致，测试结果更贴近真实场景：

• TestBinder 单元级性能测试
  如果需要先排除RabbitMQ中间件的影响，单独测试业务消费逻辑的性能，可以使用Spring Cloud Stream官方提供的TestBinder替换RabbitMQ Binder，配置spring.cloud.stream.default-binder=test即可生效，直接在单元测试中向input通道批量推送测试消息，统计业务逻辑的处理耗时、吞吐量，先优化完代码层瓶颈再做端到端测试。
• 自定义生产端压测服务
  单独写一个轻量Spring Boot应用，使用同样的RabbitMQ Binder配置绑定目标Exchange，开发触发接口或者定时任务批量发送测试消息，自行统计生产速率、消费ACK速率。这种方式没有第三方工具的适配成本，和生产环境的消息生产逻辑完全一致，适合快速验证某个参数调整后的性能变化。

3. 全链路压测方案 #

如果你的消费逻辑还包含下游调用、数据库写入等操作，可以扩展为全链路压测：给压测消息打特殊标记，配合链路追踪工具统计整条链路各节点的耗时，不仅能测出消息消费模块的性能，还能定位整个业务链路的瓶颈点。

测试注意事项：每次测试只调整一个变量（比如单次只改消费线程数，或者只改消息大小），避免多变量干扰导致无法定位性能变化原因；核心指标需要覆盖吞吐量、延迟、错误率、消息堆积量、服务与中间件资源占用几个维度。

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