由 dawei 某电商系统在大促前遭遇瓶颈：单台应用服务器吞吐量仅800 QPS，延迟飙升至1.2秒，数据库连接池频繁超时。团队没有盲目加机器，而是由后端架构师带队，聚焦三处关键优化点，两周内将吞吐量稳定提升至1650 QPS，响应时间降至420ms。
第一步，直击线程阻塞根源。原服务大量使用同步HTTP调用第三方风控接口，平均耗时380ms且无法超时控制。架构师推动改用异步非阻塞Feign客户端，并引入1.5秒硬超时与默认降级策略。同时将风控结果缓存5分钟，命中率升至73%。此举释放了62%的线程资源，Tomcat活跃线程数从210骤降至70。
AI设计草图，仅供参考
第二步，重构数据库访问路径。原代码中存在“N+1查询”问题——单次订单详情请求触发27次独立SQL，其中19条为重复查用户基础信息。通过MyBatis Plus的@SelectProvider动态拼装JOIN语句，配合一级缓存开关与二级缓存（Caffeine）预热常用用户数据，单次订单SQL降至3条，数据库QPS下降58%，慢查询归零。
第三步，精简序列化与网络开销。服务间通信原用JSON+RestTemplate，每个12KB订单对象经Jackson序列化后膨胀至18KB，网络传输占整体延迟29%。统一替换为Protobuf协议，定义紧凑schema，序列化后体积压缩至4.1KB；再启用gRPC双向流替代部分短连接HTTP调用。序列化耗时从8.6ms降至1.3ms，网络IO等待减少41%。
三次调整均在预发环境灰度验证，无业务逻辑变更，不依赖基础设施升级。优化后服务器CPU使用率稳定在55%（原峰值92%），GC频率下降76%，错误率由0.37%趋近于0。关键启示在于：吞吐量瓶颈常不在硬件，而在同步调用、低效查询与冗余序列化这三处“隐形带宽杀手”——精准定位、小步快跑，远胜于扩容与重写。