微服务代码评审该盯住哪些细节

微服务代码评审该盯住哪些细节微服务评审不能只沿着成功路径检查返回值。一次请求可能同时使用数据库连接、远程调用、线程池和缓存把等待放进错误的边界就会把下游的短暂变慢放大成连接池耗尽。评审时最好顺着请求画出时间线何时开启事务何时产生外部副作用失败时哪些状态已写入连接与任务由谁收尾。事务里别等待不可控的调用Transactional方法在数据库操作后再等待 HTTP、gRPC 或耗时计算可能让连接和锁一直持有到方法结束。具体影响取决于连接取得时机、隔离级别和 SQL但不能因为代码表面简短就忽略这段等待。下游慢下来后在途事务增加连接池排队也会随之扩大。常见改法是本地事务先写入明确的中间状态在事务外调用远程服务再用短事务更新结果。这避免了长事务却没有自动解决跨系统一致性。进程可能在本地提交后退出也可能远程成功而本地状态尚未更新所以必须配合幂等键、可恢复任务、对账或 Outbox。不能仅仅把一段方法切成三块就认定可靠。评审里经常漏掉的五处第一RPC、消息和文件操作是否被包进事务提交后发送失败怎样处理。第二Async、CompletableFuture到底使用哪个执行器队列是否有界、拒绝和关闭怎样反馈。第三连接、读取和总超时是否明确重试是否只针对允许幂等的动作。第四单例 Service 是否意外保存了请求级可变数据。第五异常捕获后是否仍返回成功受检异常的回滚规则是否符合业务补偿。这些问题都不能靠默认值猜测。默认执行器、客户端超时和事务规则会随依赖版本而不同应该回到项目配置、调用链和压测证据确认。public OrderResult create(OrderCommand cmd) { Long id transactionTemplate.execute(status - { Order order Order.waitingForPayment(cmd); repository.save(order); outbox.save(OutboxEvent.paymentRequested(order.getId())); return order.getId(); }); return new OrderResult(id, PENDING); }这个例子把订单与待发送事件放在同一笔本地事务中发布器随后可靠地投递事件。支付侧仍要以订单标识去重消费者也要能处理重复消息长期停在中间状态的订单需由后台任务查询和收敛。异常日志应保留关联标识与原因链不能把支付参数或用户数据直接暴露给外部响应。缓存相关代码也要问失效与并发回源缓存未命中时是否会让大量请求同时打到数据库更新后旧值能保留多久缓存故障时是否有更窄的降级路径。评审不是禁止优化而是让每个优化都说清资源上限和失败时的退路。规则可以进 CI验证仍要靠故障场景ArchUnit 等工具适合约束明确的依赖边界例如禁止事务方法直接依赖某类远程客户端。但它可能漏掉间接封装也可能误报因此不能取代人工理解调用流程。验收时故意让数据库、支付或消息服务变慢观察事务时长、连接池等待、重试次数和中间状态能否回落。代码评审真正要守住的是失败发生时资源不会长期占住已经写下的状态能被继续解释和处理。