容量保障
- 容量规划：以尽可能小的成本确保系统当前和未来的容量充足
- 容量治理：解决已知的容量问题，预防未知的容量问题
容量管理
容量水位：
- 业务容量水位：指的是系统中业务负载与业务容量之间的比率，计算公式为：业务容量水位 = 当前承载的请求量（事务量）/ 能承载的最大请求量（事务量） * 100%。这一指标主要衡量整个服务链路的流量，从用户接入到后端数据库。
- 资源容量水位：指的是系统中具体资源的使用情况，计算公式为：资源容量水位 = 当前消耗的资源量 / 总体可用的资源量 * 100%。这一指标关注的是CPU、内存、I/O等资源的使用情况，以识别潜在的资源瓶颈。
容量观测：
系统容量的实时监控和长期趋势预测。通过实时的容量监控大盘和定期的容量巡检，可以密切关注系统的水位状态和关键性能指标，及时发现并处理如性能退化和流量上升等问题。此外，容量管理平台和压测平台也是容量观测的重要工具，分别用于数据累积、管理和系统压测
容量分析：
评估当前资源是否满足需求、制定资源补充策略以及确定资源补充的时间节点。这一过程需要结合动态规划和最优化理论等数学模型，深入分析系统的服务特性，构建服务画像，并基于这些分析来制定精准的资源补充计划
容量处置：
指在系统容量不足时采取的应对策略，包括增加资源、内部调度、限流丢弃、功能降级和缓存优化
量化指标
SLA
- SLI 定义测量的具体指标，如 QPS、带宽等
- SLO 定义服务提供功能的期望状态，如 QPS 99 线≤100ms
QPS/TPS
通常说的系统容量是否足够，一般就是指系统或服务能否在可接受的响应时间和成功率下支撑目标 QPS/TPS
用户体验
大多数用户体验是可以与系统指标或业务指标挂钩的，这些指标就可以作为目标的一部分
容量测试
范围
- 关键路径上的核心服务
- 有明显流量峰值特征的服务
- 对响应时间敏感的服务
- 占用资源大的服务
- 历史上曾经发生过容量事故的服务、目前高峰期已经存在容量隐患的服务、新上线对容量情况未知的服务
重点链路
- 同步链路：强依赖的，调用方需要等待被调用方执行完成，各服务的容量最容易互相影响
- 异步链路：需要明确异步流量是从哪里过来的，量级有多大，高压期间否要做蓄洪，是否会由于消息重投而引起雪崩效应
- 旁支业务链路：一个很不起眼的业务，在特定的场景下被反复调用后，会形成很高的终端延时
- 高并发链路：需要做的比较多，参考[高性能](/软件工程/架构/系统设计/高并发.html)
线上测试
flowchart TD 测试开始 --> 单线程调试 单线程调试 --> 是否有异常 是否有异常 -->|是| 是否能现场解决 是否能现场解决 -->|否| 测试结束 是否能现场解决 -->|是| 逐步加压 是否有异常 -->|否| 逐步加压 逐步加压 --> 监控业务指标 逐步加压 --> 达到目标值 监控业务指标 --> 指标是否可接受 指标是否可接受 -->|否| 解决后继续加压 指标是否可接受 -->|是| 达到目标值 达到目标值 --> 摸高/脉冲/限流验证 摸高/脉冲/限流验证 --> 测试结束线下基线测试
将当前各服务的主干版本部署在基线环境上，并通过容量测试的方式获取容量指标记录备案，这些指标记录为基线指标
当有服务准备发布新版本时，就可以在基线环境上部署这个新版本，再执行同样的容量测试，将所获得的指标与基线指标进行对比，如果出现关键指标的异动，就需要介入排查，可以整合进CI流水线
容量规划预测
- 参考历史的相关数据，建立合适的模型，预测未来的容量需求，定期地和实际的数据做对比，从而调整和纠正以前的预测
针对时间序列的 ARIMA 模型
挑战：
- 不仅是钱，大容量规划还需要建数据中心，这些砸钱解决不了
- 数据中心地域的规划
- 服务器种类规划
- 流量高峰低估有季节性
- 还要考虑灾备
云上的容量保障
- 弹性扩缩容，缩容是有风险的
前进的方向：减少应用冷启动时间（GraalVM），结合传统的容量规划手段，准实时的进行扩缩容
组织建设
- 中心化容量保障团队
- 全员容量保障意识
小规模的容量保障
- 粗放式保障：择性价比高的“大头”去优先保障
- 利用好云服务商的按使用收费机制