网络延迟常被忽视，却是最大拖累
在多个服务频繁通信的场景中，网络延迟往往成为隐形杀手。比如一个订单请求要经过用户服务、库存服务、支付服务，每跳增加几十毫秒，累积起来就可能突破用户可接受的响应时间。尤其当服务跨地域部署时，物理距离带来的延迟难以靠算法优化弥补。这时候需要做的不是升级服务器配置，而是检查调用链路是否合理，能否合并远程调用，或者引入本地缓存减少跨节点访问。
curl -w "\nConnect: %{time_connect} TTFB: %{time_starttransfer}\n" -o /dev/null -s http://api.example.com/order这条命令能帮你测出每次请求的真实连接时间和首字节返回时间，是排查网络瓶颈的实用工具。
数据库连接池配置不当，系统卡顿如常
很多团队发现高峰期接口变慢，第一反应是查代码逻辑，却忽略了数据库连接池。连接数设得太小，并发一上来大量请求排队等连接；设得太大，数据库又扛不住，连接切换开销反而拖垮性能。某电商平台曾因把连接池从20盲目调到500，导致数据库线程竞争剧烈，CPU飙到90%以上。合理的做法是结合平均响应时间和并发量计算理论值，再通过压测微调。
例如，若单个请求处理耗时约50ms，系统需支撑每秒400并发，则理论上至少需要 400 × 0.05 = 20 个连接。实际可设置为30~40，并监控数据库侧负载变化。
日志写入挤占关键资源
有些服务在处理核心业务的同时，同步写入大量调试日志到磁盘或远程日志系统，这在高并发下会严重争抢IO带宽。曾有个金融系统的对账服务，每笔交易都记录详细上下文，结果在凌晨批量处理时磁盘IO利用率冲到100%，主流程也被拖慢。后来改用异步批量写入，并按级别过滤非必要日志，处理速度提升了近三倍。
调整日志级别只是第一步，更进一步可以引入采样机制：只对1%的请求记录详细轨迹，其余保留关键节点信息。
缓存失效策略引发雪崩
缓存本是用来减轻后端压力的，但设计不好反而会引发更大问题。比如大量缓存项设置相同过期时间，一到整点集体失效，所有请求瞬间打到数据库。这种现象在促销活动结束后特别常见。解决方案之一是给过期时间加随机扰动：
ttl = 3600 + random.randint(0, 600) // 基础1小时，浮动0~10分钟这样能有效分散失效时间点，避免流量突刺。另外，对于热点数据，可考虑使用永不过期+主动更新的方式维持缓存命中率。
消息队列堆积反映消费能力不足
当看到消息队列长度持续增长，说明消费者处理速度跟不上生产节奏。这背后可能是单机处理能力见顶，也可能是消息分配不均。比如某个消费者实例因GC频繁暂停，导致分区消息积压。这时光增加消费者数量未必奏效，得先看监控指标：CPU、内存、GC日志、消息处理耗时分布。
有时候问题出在消息体过大，序列化反序列化耗时太长。将原本传整个对象改为只传ID+必要字段，再由消费者按需查询，往往能显著提升吞吐量。