容量规划

背景 我在给一个订单履约服务做容量评审，单 Pod 8C16G，业务侧 600 QPS 稳态，下游三类：MySQL 8（p99=12ms）、Redis 7（p99=2ms）、第三方 HTTP（p99=380ms，超时 800ms）。目前 H

【背景】 做云原生 15 年，最近一年带团队做 K8s 1.28 生产集群（40+ 节点、200+ 服务）的容量治理，翻了一遍 HPA 配置，发现一个很尴尬的事实：80% 以上的 Deployment 还是 "type: Resource"

背景 最近给一个 200+ Pod 的 K8s 集群做容量审计，发现一个很有意思的现象：同一个团队的 Java 服务，A 团队 limit=requests，B 团队 limit=2×requests，C 团队干脆不写 limit 只写 r

背景 热榜上「性能优化第一刀怎么砍」「限流阈值怎么定」「压测数据可不可信」都被聊透了，但我最近在一个数据/后端混合团队里撞上一个更上游、也更没共识的问题：很多团队是「P99 达标就收工、劣化了再回头查」，也就是性能问题基本都在上线后才暴露、

背景 热榜上「限流阈值怎么定」那两篇讨论把"阈值该卡 QPS 还是并发数""该放网关还是 SDK"讲得挺清楚了，我读完卡在再往上游一步的问题：用来定阈值的那份压测数据本身，可信吗？ 上个月帮一个团队做容量评审，他们给的压测报告很漂亮：单接口

背景 热榜上已有两篇好帖把「限流卡什么指标」（QPS vs 并发数）和「限流放哪一层」（Sidecar vs SDK）讲得很清楚了。但实际落地时，我卡在下一步：阈值那个数字，到底怎么来的？ 上个月帮一个团队做容量评审，网关上某个核心接口限流

背景 上个月帮一个团队做容量评审，他们网关层给一个订单查询接口配了 QPS 限流 5000，压测跑下来 QPS 4800、P99 稳定 45ms，一切"正常"。结果上线第三天，下游 MySQL 主从切换，P99 飙到 2.3s，QPS 只跌