容量规划到底该用「固定池」还是「动态扩缩」：线程池/连接池的容量，是设计期定死还是运行期自适应？

【背景】 我做了 10 年高并发服务，最近把几条核心链路的容量策略重新盘了一遍，发现团队里对「池子多大」这件事其实没有共识，而且不同人脑子里跑的是两套完全不同的模型：

一套是「固定容量派」：用 Little's Law（L = λ × R）或者 CPU-bound / IO-bound 经验公式在设计期算出线程池 / 连接池大小，写进配置，上线后基本不动，容量超了就靠限流、降级、拒绝兜底。

另一套是「动态扩缩派」：上 Sentinel / Hystrix 的动态线程池、或者基于负载信号（pending 数、RT 分位数、队列深度）在线调整池子大小，让容量跟着流量走。

两种做法我都用过，也见过两种做法各自翻车：

• 固定池翻车：大促前流量涨了 30%，池子没跟上，P99 直接打穿 SLO，事后复盘发现容量预留不足。
• 动态池翻车：下游数据库连接数被上游动态扩到 200+，把 DB 打挂，整个集群雪崩，事后发现「动态扩」其实把上游的容量不确定性直接传导给了下游。

【常见分歧 / 几种做法】

1. 纯固定 + 留 30~50% headroom，超了靠限流；
2. 纯动态，用 RT / 队列深度 / active 占比做信号，在线扩缩；
3. 混合：固定池做「上限」，动态只在 [min, max] 区间内调整；
4. 按下游类型区分：对 DB / 外部 API 用固定，对内部 RPC 用动态；
5. 容量直接交给 K8s HPA 扩副本，单实例池子保持固定。

【我的倾向与理由】 我倾向「固定容量为主、动态为辅，且动态的边界由固定容量计算得出」，核心逻辑是：

1. 容量是「设计变量」，不是「运行时变量」。下游的承载能力是确定的（DB max_connections、外部 API 的 QPS 配额），上游动态扩到 300 不会让下游变快，只会把排队时间从「可预期的等待」变成「不可预期的长尾」——这正是 P99 抖动的来源。
2. 动态扩缩把「容量不确定性」从上游转移到了下游。固定池 + 限流，至少不确定性是「本地可观测、可拒绝」的；动态扩让不确定性变成「对下游的突发冲击」，这是雪崩的经典路径。
3. 固定容量配合 Little's Law 有一个隐藏好处：它强制你在设计期就把 R（驻留时间）算清楚，这比「先上线、RT 高了再扩」的反馈回路要快得多，也更可控。
4. 动态扩缩真正有价值的场景，是「流量模式高度不可预测 + 下游容量富余 + 扩缩信号可靠」三者同时满足，这在核心链路上很少见。

【想听大家在什么场景下怎么选】 特别想收集几个数据点：

• 你们线上线程池 / 连接池是固定还是动态？min/max 怎么定的？
• 如果下游是 DB / 外部 API，你们敢用动态扩吗？出过事吗？
• HPA 扩副本 vs 单实例扩池子，你们怎么取舍？
• 有没有「动态扩缩反而放大了 P99」的真实案例？信号是什么、扩到多大、什么时候发现的？

这个话题我觉得比「池子调多大」更本质——它决定的是「容量不确定性由谁承担」，欢迎拍砖。