解读

面试官真正想考察的是：

1. 你是否理解“并发度 100 触发限流”只是业务网关或流量入口的自我保护阈值，而非系统真正的容量天花板；
2. 能否用科学、可落地的性能工程方法，在不影响线上或灰度环境的前提下，把“被限流掩盖”的真实并发上限量化出来；
3. 能否把压测结果翻译成研发、运维、SRE 都能看懂的容量模型，并给出可执行的扩容或优化建议。

国内面试场景里，回答必须兼顾“安全合规”与“快速验证”，否则会被追问“你敢直接打线上？”或“你怎么保证不出故障？”。

知识点

1. 并发度（Concurrency）≠ QPS：并发度是“同一时刻正在处理的请求数”，QPS 是“每秒新建请求数”，二者通过 RT（Response Time）换算：Concurrency = QPS × RT(s)。
2. 限流策略：常见有 QPS 限流、并发数限流、令牌桶、漏桶、信号量。题目里“并发度 100 触发限流”大概率是信号量或并发连接数限流。
3. 性能拐点：当资源（CPU、线程、连接、锁、IO）任一达到 80%+ 或出现明显上升，RT 开始指数级增长，此时并发度即为“实际上限”。
4. 影子流量 / 流量镜像：国内大厂（阿里、腾讯、字节）普遍用 Go/JAVA Agent 把线上请求复制到影子环境，影子环境关闭限流，结果最接近真实。
5. 阶梯模型（Stepping Model）：国内金融、运营商合规要求“每级阶梯不超过 10% 流量”，单级持续 3-5 分钟，禁止一次性打满。
6. 业务 SLA：电商大促 99.9% 请求 RT≤500 ms；金融支付 99.99% 请求 RT≤200 ms。上限必须同时满足 SLA，否则无意义。
7. 容量公式：目标并发上限 = min(CPU 上限并发，内存上限并发，池化资源上限并发，下游依赖上限并发) × 0.8（保留 20% 缓冲）。

答案

回答时分四步，每一步给出可落地的“国内可行方案”，并主动把风险点和回退预案说出来，体现资深度。

第一步：明确目标与约束
“并发上限”指在 SLA 限定 RT 下系统能稳定承载的最大并发度，而非“极限崩溃值”。必须排除限流干扰，同时不能触碰线上可用性红线。

第二步：建立“去限流”的等效环境

1. 影子集群：用 Kubernetes 单独拉起一套与生产同配置、同数据版本的影子 Deployment，注册中心打标“shadow”，网关层对该标签关闭限流插件。
2. 流量镜像：在 Ingress 或 Service Mesh（Istio/Envoy）做流量镜像，把线上 100% 请求复制到影子集群，同时影子流量不返回用户，避免脏写；若业务不允许镜像，则用 Gatling/JMeter 录制线上 1 小时流量样本，再做比例回放。
3. 数据隔离：影子库使用 MySQL 只读实例 + Redis 前缀隔离，防止污染；若需写操作，采用影子表 + 事务回滚脚本，压测完自动清理。

第三步：设计“阶梯递增”压测脚本

1. 并发梯度：从 0 开始，每级增加 10%（10→20→30…），单级持续 5 分钟，保证 95th RT 稳定后再升一级。
2. 监控维度：
   • 应用：QPS、RT、99th RT、错误率、线程池活跃数、队列长度；
   • 容器：CPU%、Memory%、Pod 重启次数；
   • 中间件：连接池使用率、Redis 命中率、Kafka 消费延迟；
   • 限流开关：确认影子集群限流插件已关闭。
3. 拐点判定：当任一资源≥80% 或 99th RT 超过业务阈值（如 500 ms），记录当前并发值 C，再回退一级验证可恢复，即确认 C 为“实际并发上限”。

第四步：输出容量报告与优化建议

1. 报告核心：
   “在 SLA（99th RT≤500 ms）约束下，影子集群单实例并发上限为 120，CPU 是首要瓶颈（85%），线程池 200 配置仍剩 40% 余量，建议：
   a) 线程池可下调至 150，减少上下文切换；
   b) 热点接口 /order/create 内部调用 Redis 使用 Pipeline，预计 RT 下降 30%，并发上限可提升至 150；
   c) 横向扩容：每增加 1 个 Pod，系统并发上限线性 +120，建议生产按 1.5 倍冗余部署。”
2. 风险预案：
   • 压测全程由值班研发、SRE 双人旁路监控，CPU>90% 或错误率>1% 立即触发自动熔断，脚本 30 秒内停流；
   • 影子环境独立域名，万一配置误切用户流量，DNS 30 秒 TTL 可快速回滚。

拓展思考

1. 如果公司不允许搭影子集群，只能在生产压测，怎么办？
   采用“凌晨低峰+熔断保护”策略：

   • 选 02:00-04:00 自然并发<5% 时段；
   • 在网关层动态调整限流阈值，从 100 逐步上调到 120、150…，每级持续 3 分钟；
   • 实时监控业务黄金指标（订单成功率、支付回调延迟），一旦下跌 5% 立即回滚限流阈值并停止压测。
     此方法风险高，必须提前报备变更，且需值班经理、DBA、SRE 三方在线。

2. 如果服务是 Serverless（函数计算、Knative），并发上限由平台自动伸缩，如何评估？
   核心指标从“并发度”转为“冷启动+RT”：

   • 用 burst 模型一次性发 200 并发，观察首包 RT 是否因冷启动劣化；
   • 记录平台伸缩到稳定所需的“扩容窗口”T，换算业务可接受的最大突发并发 = 单实例并发 × (T 内可完成扩容的实例数)。
     最终给出“并发突刺缓冲池”建议：提前预热最小实例数或采用“定时预留”策略，降低冷启动带来的 RT 抖动。

3. 评估完并发上限后，如何持续守护？
   把压测脚本固化到 CI/CD，每周跑一次“容量基线”Job；
   将拐点并发值、RT、CPU 指标录入 Prometheus，配置告警规则：

   • 当周并发上限较基线下降>10% 触发“容量腐化”告警；
   • 自动创建 Jira 工单，指派给最近一次上线 commit 的研发，形成闭环。