微服务容量规划需从服务粒度、运行时特征、协同关系三维度综合评估：识别资源敏感型服务、采集真实容器指标、标注业务周期特征；关注节点资源倾斜与碎片化；结合调用链开展端到端协同压测；用动态预测模型替代静态配额，分级设置水位线并反向映射sla为资源基线。
微服务架构拆分后，集群资源消耗不再由单体应用统一承载，而是分散到多个独立服务中，资源使用呈现碎片化、不均衡、动态波动等特点。因此，容量规划不能只看总量，而要从“服务粒度+运行时特征+协同关系”三个维度综合评估。
按服务维度做资源画像
每个微服务对CPU、内存、I/O、网络的偏好不同，需单独建模：
- 识别资源敏感型服务：比如订单计算服务常是CPU密集型（嵌套循环、规则引擎），商品搜索服务更依赖内存与磁盘I/O（Elasticsearch缓存、索引加载），支付回调服务则可能突发高网络连接数；
- 采集真实负载下的容器指标：在生产环境或影子流量下，用cAdvisor、Prometheus等工具持续采集各服务Pod的CPU request/limit、内存RSS、网络收发包量、文件描述符使用率；
- 标注典型业务周期特征：例如电商系统中，库存服务在秒杀开始前10分钟内存预热上升，订单服务在支付成功后30秒内出现短暂CPU尖峰——这些节奏必须纳入容量模型。
关注节点级资源倾斜与碎片化
拆分后若缺乏调度协同，容易导致集群资源“看着够、实际用不上”：
- 检查节点部署密度是否失衡：比如某节点同时部署了高CPU型（风控服务）和高内存型（用户画像服务），二者峰值错开尚可，但若叠加就触发驱逐；
- 识别资源请求（request）与实际使用（usage）长期偏差：若某服务长期只用20%的内存request，却占着1Gi限制，就会造成内存碎片；同理，过度保守的CPU request会导致K8s调度器无法有效打包；
- 验证反亲和与拓扑约束配置：避免关键服务（如数据库代理、配置中心）被集中调度到同一物理机，放大单点故障影响面。
结合调用链与依赖关系做协同压测
单个服务达标不等于整体可用，跨服务调用会放大资源压力：
- 构造端到端业务链路压测场景：不只是压“下单接口”，而是模拟用户从浏览→加购→提交订单→扣库存→发通知→更新物流状态的完整路径，观察各环节服务的资源联动变化；
- 监控跨服务资源传导效应：例如商品服务响应变慢，会导致前端网关连接堆积，进而推高网关内存与文件描述符占用；下游库存服务超时重试增多，又反过来加剧其CPU与线程池压力；
- 设置分级容量水位线：核心链路（如支付）保留30%冗余，非核心链路（如评价推送）允许在资源紧张时自动降级或限流，避免争抢。
用动态模型替代静态配额
固定资源分配难以适应业务波动，建议引入轻量级弹性策略：
- 基于历史趋势预测扩容时机：用过去7天同时间段的QPS与CPU usage拟合回归曲线，当预测值逼近当前limit的85%时触发水平扩缩容；
- 对长尾延迟服务启用垂直伸缩：如P999耗时持续超标且伴随高GC频率，优先调高JVM堆内存limit而非盲目加实例；
- 将SLA承诺反向映射为资源基线：例如“99.9%请求
