Spring Boot服务S压测：无需修改系统B注入模拟ResultSet可行吗？

核心思路 #

要在不修改系统B代码的前提下替换数据库查询结果，本质是拦截数据库查询的执行链路，用模拟的ResultSet替代真实查询结果，同时要适配压测场景的性能要求（避免模拟逻辑拖垮压测数据的真实性）。

各框架的适用性分析 #

1. Mockito（结合动态代理能力） #

• 可行，但需调整配置：
  • 必须将Mockito的依赖作用域从test改为compile或runtime，确保压测环境能加载其代理逻辑。
  • 核心操作是通过Mockito.mockStatic()或动态代理，拦截系统B中获取数据库连接、执行查询的核心类（比如DataSource、Statement、PreparedStatement）。例如拦截Statement.executeQuery()方法，直接返回预先构造好的自定义ResultSet。
  • 注意事项：需要精准定位系统B的查询入口类（比如封装后的DAO层、JDBC工具类）；压测前要确保代理逻辑正确初始化，压测后清理代理避免影响其他流程。
  • 性能影响：动态代理会带来少量性能开销，但压测场景下如果模拟逻辑简单，该开销可忽略不计。

2. JOOQ #

• 不适合当前场景：
  • JOOQ是查询构建与ORM工具，本身没有提供无代码修改的ResultSet替换能力。除非系统B完全基于JOOQ DSL执行查询，且允许修改配置注册自定义ExecuteListener拦截结果，但这违反了“无需修改B代码”的要求。

3. TestContainers #

• 完全不适用：
  • TestContainers的作用是启动容器化的真实数据库，提供接近生产的测试环境，无法直接返回自定义的ResultSet。它适合需要真实数据库交互的测试，但不符合你替换查询结果的需求。

替代方案：字节码增强工具（如ByteBuddy、ASM） #

如果Mockito的动态代理无法覆盖系统B的查询逻辑（比如系统B使用原生JDBC且类加载机制特殊），可以用字节码增强工具直接修改系统B中查询方法的字节码，在运行时替换返回结果。

• 实现方式：编写增强逻辑，在Statement.executeQuery()或DAO层查询方法执行后，将返回的ResultSet替换为自定义模拟对象。
• 优势：无需修改系统B代码，兼容性更强，性能比动态代理略优。

压测场景的关键注意事项 #

• 模拟ResultSet的真实性：自定义ResultSet的字段类型、数据量、结构必须与真实数据库返回完全一致，否则压测数据会失真（比如服务S处理不同结构数据的性能差异）。
• 轻量化模拟逻辑：模拟逻辑要尽量简单，避免引入额外IO或计算开销，确保压测结果能真实反映服务S的处理能力。
• 严格环境隔离：必须通过配置开关（如系统属性、环境变量）控制模拟逻辑的启停，绝对禁止在生产环境启用。

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