如何从架构层面强制RPC远程调用脱离数据库事务以规避性能问题？

针对你遇到的事务内RPC调用导致连接池耗尽的问题，从架构层面做约束确实是根治的办法，这里有几个经过实践验证的可行方案，覆盖编码规范、框架增强和架构设计三个维度：

• 先定义一个@NonTransactionalRPC注解，专门标记所有需要发起RPC调用的方法，明确这个注解的方法不能被事务方法直接调用。
• 用Spring AOP写一个切面，拦截所有带有@Transactional的方法：如果检测到方法内部直接调用了RPC客户端（可以通过你们统一的RPC客户端接口来识别），或者调用了带@NonTransactionalRPC的方法，直接抛出运行期异常；如果是开发环境，甚至可以用APT注解处理器在编译阶段就报错，把问题扼杀在摇篮里。
• 同时在团队编码规范里明确：所有RPC调用必须封装在带@NonTransactionalRPC的方法中，且这些方法只能被应用层或者无事务的服务层方法调用。

• 基于你们的Spring+Hibernate自定义框架，扩展事务管理和RPC客户端的逻辑：
  • 在RPC客户端的代理类里，发起调用前先检查TransactionSynchronizationManager.isActualTransactionActive()，如果当前线程有活跃事务，直接抛出异常并记录告警日志，从调用入口就阻断事务内的RPC请求。
  • 或者修改事务管理器的逻辑，当事务开启时，临时禁用RPC客户端的实例获取，直到事务提交/回滚后再恢复。
• 另外可以给连接池加监控联动：如果发现事务内有RPC调用的情况，直接标记为违规操作，开发测试环境直接阻断，生产环境触发告警通知运维。

• 重新明确三层架构的绝对边界：
  • 应用层：只做请求接收、参数校验，负责调用服务层或RPC客户端，绝对不允许开启事务。
  • 服务层：处理业务逻辑和事务，但禁止在事务方法内直接发起RPC调用，必须把RPC调用剥离到单独的无事务方法中，通过异步（比如@Async）或者事务提交后触发的方式执行。
  • 数据访问层：只负责数据库CRUD，完全不涉及任何RPC操作。
• 配合SonarQube这类代码审查工具，自定义扫描规则：扫描所有带@Transactional的方法，检查是否包含RPC客户端的调用代码（比如特定的类名前缀、方法名），一旦发现就标记为严重问题，阻止代码合并到主干分支。

• 写一个统一的RpcAfterTransactionExecutor工具类，封装所有RPC调用逻辑：
  • 工具类内部自动检查当前线程的事务状态：如果有活跃事务，就把RPC调用加入到事务提交后的执行队列（用Spring的TransactionSynchronizationManager.registerSynchronization()实现）；如果没有事务，就直接执行调用。
  • 要求所有开发人员必须通过这个工具类发起RPC调用，禁止直接调用RPC客户端。这样既保证了RPC调用一定在事务之外，又能保证业务一致性——只有当本地事务提交成功后，才会触发对外部模块的调用。

这些方案都能从架构层面形成刚性约束，避免后续开发中再出现类似的连接池耗尽问题。其中，自定义注解+AOP+代码审查的组合是最容易快速落地的，既能在编码阶段就提示问题，又能在CI/CD环节做拦截，从源头杜绝违规写法。

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