📚 课程目录第2章微服务容量规划核心概念与知识体系

微服务容量规划核心概念与知识体系

容量规划是微服务架构的“压舱石”——它决定了系统能否平稳应对流量洪峰。本章将拆解5个核心概念的关联与面试高频提问逻辑，帮你构建从理论到实践的完整知识链。

面试提示：面试官常通过“QPS/TPS如何推导资源需求”这一链条，串联你对所有概念的理解。下面三个问答卡片覆盖了最典型的考察角度。

面试问题	服务拆分粒度如何影响容量规划？请举例说明。
考察点	理解微服务拆分与资源开销的权衡；能否从调用链、数据一致性、资源碎片等角度分析。
回答框架	1. 拆分过细：增加网络开销、服务数量膨胀、资源碎片化；2. 拆分过粗：单点压力大、难以独立扩缩；3. 推荐按业务域/变更频率拆分，通过基准测试验证。
示例回答	“过细会导致每笔交易跨越5次RPC，QPS翻倍而资源利用率下降30%。通常将内聚性强的接口聚合为一个服务，再按峰值预估实例数。例如订单服务拆分后，核心写接口单独部署，节省40%节点。” （共96字）
可能追问	如何衡量“合理的服务粒度”？有没有量化的指标？
避坑提醒	❌ 只讲理论不讲案例；✅ 必须结合具体服务（如订单、支付）说明粒度选择逻辑。

面试问题	请说明QPS和TPS的计算方式，以及它们如何指导容量规划？
考察点	是否区分QPS（查询）和TPS（事务）；是否理解峰值、均值、毛刺的处理；能否推导所需实例数。
回答框架	1. 定义QPS=总请求/秒，TPS=完成事务/秒；2. 压测获取单实例极限QPS；3. 用公式：实例数 = 预估峰值QPS / (单实例QPS × 安全系数)。
示例回答	“先压测得到一台2C4G实例支撑200 QPS（写接口）。双11峰值预估10000 QPS，考虑40%冗余，实例数=10000/(200×0.7)≈72台。同时监控TP99延迟，确保弹性伸缩阈值合理。” （共88字）
可能追问	安全系数如何确定？如果QPS突然翻倍怎么办？
避坑提醒	❌ 混淆QPS和TPS；✅ 明确区分读写场景，并强调使用TP99而非平均值。

面试问题	什么是弹性伸缩？在微服务中你会如何设计一套弹性伸缩方案？
考察点	对弹性伸缩类型（水平/垂直）、触发指标、冷却时间、数据一致性等细节的掌握；是否具备生产环境经验。
回答框架	1. 选择水平伸缩为主；2. 指标选择：CPU/内存+业务QPS自定义指标；3. 设置稳定窗口和冷却时间避免抖动；4. 配合优雅上下线与健康检查。
示例回答	“K8s HPA基于自定义指标（如队列深度）自动扩缩。设置最小副本2、最大20，冷却时间120秒，避免频繁伸缩。同时用PodDisruptionBudget保证缩容时请求不中断。” （共97字）
可能追问	如果扩容后请求依然超时，如何定位？
避坑提醒	❌ 只提K8s HPA的简单配置；✅ 必须涉及预热（warm-up）、服务发现、慢启动等工程细节。

📍 知识结构关键公式：

预估实例数 = 峰值QPS / (单实例极限QPS × 安全系数)
资源预留 = 预估实例数 × 单实例资源需求 × 1.3（Buffer）

安全系数通常取0.6~0.8，Buffer应对突发抖动。

项目名称	双11大促容量保障——订单、支付、库存服务
业务背景	双11流量较日常激增8~10倍，需提前预测资源并设计弹性策略，保障SLA（成功率≥99.9%，TP99≤200ms）。
规模指标	峰值QPS 120万（订单服务）、2万TPS（支付事务）、服务实例总数2000+，涉及Redis、MQ、MySQL等50+组件。
技术栈	Spring Boot + Spring Cloud Gateway + Kubernetes + Prometheus + HPA + Sentinel + ELK。
核心难点	链路级容量匹配：上游扩容但下游数据库连接池打满热点Key导致单实例过载：库存扣减Redis热点冷启动延迟：新Pod从创建到处理请求耗时30秒
面试高频追问	如何确定扩容的“优先顺序”（哪个服务先扩）？冷启动问题如何解决？（预热/就绪探针/缓存预热）容量规划中如何模拟突增流量？（全链路压测+TICK脚本）
可迁移回答话术	“先对整个调用链做全链路压测，找到瓶颈服务（通常是数据库或缓存）。然后根据历史流量曲线+业务增长系数建立线性模型，预留30% Buffer。考虑冷启动，设置HPA的minReplicas为日常峰值的60%，保证快速响应突发。对于热点，采用本地缓存+限流降级。”

⚠️ 避坑提醒：很多候选人只谈“弹性伸缩”，却忽略了容量预测和依赖链路匹配。大厂面试官更关心你能否用真实案例证明“预判+自适应”的思维方式——这才是核心加分项。