解读

面试官想验证三件事：

1. 你是否理解“容量模型”=“并发用户×业务配比×资源系数”这一动态公式，而非静态硬件台账；
2. 你是否能把“白天集中→凌晨分散”翻译成可量化的负载特征变化（峰值QPS、并发在线、资源利用率曲线）；
3. 你是否具备“自适应”闭环：监控→预测→决策→弹性→验证，并能在国内主流技术栈（阿里云/腾讯云/华为云+K8s+微服务+中间件）里落地。

知识点

1. 容量模型四要素：业务流量模型、资源消耗模型、弹性策略模型、成本模型。
2. 国内云原生弹性三件套：HPA（基于CPU/内存/QPS）、VPA（垂直调规格）、CA（节点级伸缩）。
3. 时间序列预测：PromQL + Prometheus Rule、阿里云SLS智能预测、腾讯云TSF时序预测。
4. 微服务治理：Sentinel 流控、Nacos 配置热推、Spring Cloud Gateway 动态限流。
5. 灰度验证：凌晨低峰期通过 ChaosMonkey 或阿里云AHAS 注入故障，验证新容量水位。
6. 合规与成本：国内凌晨2-6点带宽单价低，但需报备“变更窗口”，避免审计风险。

答案

我会把“自适应”拆成五步闭环，全部用开源或国内云厂商原生能力落地，不重复造轮子。

第一步，实时画像校准
利用现有埋点与AccessLog，把“白天集中”与“凌晨分散”分别抽象成两个流量模板：

• 白天模板：高峰QPS=1.2万，在线并发=3万，读写比=8:2，热点Key集中在商品SKU。
• 凌晨模板：QPS=2千但持续6小时，在线并发=5千，读写比=2:8，热点消失，批量任务增多。
  通过Flink实时作业每10分钟更新一次模板参数写入Nacos，作为后续弹性的输入。

第二步，预测式伸缩
Prometheus里用predict_linear(qps[2h], 3600)提前1小时预测QPS，结合阿里云SLS的“智能异常检测”输出置信区间。当预测值与当前HPA目标差距>30%时，触发一次“预扩容”而不是等CPU飙高再扩容，提前量≈冷启动时间+JIT预热时间（Java应用约3分钟）。

第三步，双层弹性

1. Pod层：HPA指标不再只盯CPU，而是自定义指标qps_per_pod，阈值=“模板QPS÷目标单Pod容量”。
2. 节点层：Cluster Autoscaler加上“包年包月+按量”混合策略，凌晨低峰优先缩到包年包月节点，降低成本；白天高峰弹出按量节点，十分钟内交付。
   国内云厂商的“竞价实例”在凌晨富余，可设置50%的Pod容忍度，失败时快速重调度到按量节点。

第四步，自适应限流与降级
凌晨分散流量虽低，但批量任务会打满线程池。用Sentinel把“读”和“写”分成两条链路：

• 读链路：令牌桶，阈值随HPA当前副本数线性调整，公式threshold = base_threshold × current_replicas。
• 写链路：漏桶+队列等待，防止批量任务把数据库连接池瞬间打满。
  规则通过Nacos下发，版本化，支持秒级回滚。

第五步，持续验证与反馈
每周二凌晨2点触发一次“空跑演练”：

1. 用阿里云PTS/JMeter脚本模拟“凌晨模板”流量，持续30分钟；
2. 同时注入ECS节点宕机、Redis慢查询、MySQL主备切换三类故障；
3. 记录“实际CPU利用率/预测利用率”比值，若>1.2则调低HPA阈值5%，若<0.8则调高5%，实现模型自学习。
   演练报告自动归档到Confluence，抄送SRE、测试、财务，满足国内审计要求。

通过这五步，容量模型不再是一份Excel，而是一个可灰度、可回滚、可审计的“代码化”配置，白天与凌晨切换时无需人工值守，SLA保持99.9%，成本下降18%（以去年双11后实际数据为例）。

拓展思考

1. 如果业务进一步细分出“早晚高峰+凌晨批量+节假秒杀”三维模型，可用K-means对历史QPS聚类，自动生成N个模板，HPA配置由ConfigMap模板化渲染，实现“一键切换”。
2. 国内金融类客户要求“可解释性”，需要把预测公式、弹性决策记录到区块链或日志审计系统，便于央行检查。
3. 当应用出现“冷启动过长”导致弹性失效时，可引入阿里Dragonwell的AppCDS、腾讯Kona的CRaC，做快照恢复，把Java启动时间从60秒降到5秒以内，让“预扩容”真正落地。