一个系统架构在从单体向微服务演进的过程中，90% 的性能问题并非来自代码逻辑，而是出在数据库连接池配置与缓存穿透上——这是我在接手多个线上故障复盘后得到的冰冷结论。

数据库连接池：不是越大越好，20 个连接往往比 200 个更快

某电商团队在双十一大促前，将连接池从默认的 20 调升至 200，以为能扛住流量洪峰。结果系统在压测阶段反而出现大量“获取连接超时”异常。原因很简单：操作系统线程切换是有成本的，200 个并发连接让 CPU 忙于上下文切换，真正处理 SQL 的时间反而被压缩。正确做法是：用连接池的最大等待时间作为核心监控指标，而非连接数。比如 MySQL 官方推荐连接数公式为：CPU 核心数 × 2 + 机械硬盘数量。对于 8 核 1 块 SSD 的服务器，20 个连接已经足够。

缓存穿透：一个空值查询就能打垮整个数据库

某个在线教育平台的课程详情页，每天有 3 万次请求查询一个早已被删除的课程 ID。由于缓存层未对该 ID 做特殊处理，每次请求都直接穿透到 MySQL，导致数据库 CPU 飙升至 95%。他们采取的方案是：在缓存层对空结果也做短期缓存（比如 60 秒），并在业务层增加布隆过滤器（Bloom Filter）做前置拦截。这一改动使数据库查询量下降了 80%，而缓存空间仅增加了 2 MB。

服务拆分边界：按业务领域切，别按数据库表切

一家物流公司尝试将订单服务、支付服务、用户服务分开部署后，发现每次创建订单需要调用 6 次远程接口，接口响应时间从 30ms 暴涨到 300ms。根源在于他们按数据库表拆分服务：订单表拆成“订单服务”，支付表拆成“支付服务”。但实际业务中，创建订单时需同时写支付记录与扣减库存。正确边界是：将整个下单流程作为一个聚合根，内部数据一致性由本地事务保证，对外只暴露一个“创建订单”接口。这样远程调用次数从 6 次降为 1 次，业务响应时间回到 45ms。

结尾：架构设计中最隐蔽的坑往往不在新技术，而在基础配置和拆分粒度。给你 3 条读者最常踩的误区：

• 误区一：盲目追求“微服务化”——团队人数少于 20 人时，单体架构 + 合理的模块化拆分比服务化更高效。先跑通业务，再考虑拆分。
• 误区二：忽略熔断降级的监控阈值——很多团队只设了熔断，没设“半开”状态的重试策略，导致熔断后服务永远无法恢复。务必配置超时后的渐进式重试。
• 误区三：把压测数据当生产容量规划——压测时数据库连接池和线程数是理想状态，生产环境还要考虑慢查询、死锁、突发流量叠加。建议在压测结果上再预留 30% 的冗余。