服务扩容与容量评估手册
服务扩容与容量评估手册
本文档旨在新人在面临热门活动时，系统性地进行容量评估和服务扩容，确保系统稳定性和用户体验。
适用场景：
- 大促活动（双11、618等）
- 产品发布
- 节假日流量高峰
- 突发流量事件
- 系统重构上线
…关键术语：
- 基础指标
- QPS：每秒查询数（Queries Per Second），衡量系统处理能力
- RT：响应时间（Response Time），请求处理耗时
- P99/P95：99%/95%分位数响应时间，表示99%或95%的请求响应时间不超过该值
- 可用性指标
- RTO：恢复时间目标（Recovery Time Objective），可接受的服务恢复时间
- RPO：恢复点目标（Recovery Point Objective），可接受的数据丢失时间点
- MTBF：平均故障间隔时间（Mean Time Between Failures），衡量系统可靠性
- MTTR：平均修复时间（Mean Time To Repair），衡量系统可恢复性
1. 核心原则
- 容量非算术：扩容绝非简单的 峰值QPS / 单机QPS
- 评估是基石：必须与产品、运营深度沟通，获取准确流量预估
- 压测即真理：任何理论模型都必须通过全链路压测验证
- 自动化目标：杜绝手动低效操作，追求自动化完成资源申请、部署、扩缩容
- 全链路视角：应用层仅是起点，下游依赖必须同步评估与扩容
- 安全与合规：新扩容实例必须与现网保持完全一致的安全配置
- 成本意识：一切扩容行为需考虑成本，活动结束后必须及时缩容
- 数据驱动：所有扩容决策必须基于数据，避免凭经验臆断
- 渐进式扩容：采用小步快跑的方式，避免大规模扩容风险
- 监控先行：扩容前确保监控体系完善
2. 容量评估流程
流量预估
- 总访问量评估
- 核心业务链路分析
- 用户行为模式分析
QPS计算
- 平均QPS = 总请求量 / 活动总时长
- 峰值QPS评估（历史数据或经验系数）
- 区分读QPS与写QPS
单机容量评估
安全水位主要看服务重要程度，重要服务可适当冗余，调整水位数值。
- 多维度压测（CPU、内存、IO、网络等）
- 安全水位设定（50%-70%）
- SLA对齐验证
机器数量计算
- 理论机器数 = 峰值QPS / 单机安全QPS
- 添加冗余（30%-50%）
- 考虑部署策略影响
3. 全链路依赖评估
| 依赖类型 | 评估要点 | 负责团队 |
|---|---|---|
| 数据库 | 连接数、读写性能、慢查询 | DBA |
| 缓存 | 带宽、连接数、容量 | Redis团队 |
| 消息队列 | 分区数、消费者数 | 中间件团队 |
| 第三方服务 | QPS限制、配额申请 | 接口人 |
| 带宽 | 入口/出口带宽 | 网络团队 |
| 中间件 | 注册中心压力 | 中间件团队 |
4. 服务扩容流程
- 预案制定与评审
- 资源准备与部署
- 全链路压测
- 流量切换（含预热）
- 活动期间监控保障
- 活动后缩容
5. 监控与保障
核心监控指标
- 应用层：QPS、响应时间、错误率
- 系统层：CPU、内存、IO、网络
- 依赖层：数据库、缓存、消息队列
- 业务层：转化率、成功率、关键指标
告警分级
- P0：系统不可用、核心业务失败
- P1：响应时间显著上升、错误率上升
- P2：次要指标异常
6. 案例分析
安全水位、冗余台数需综合服务重要程度、成本相关考虑。
我们以秒杀活动扩容案例为例：
- 背景：预计峰值QPS 10万
- 单机极限：3万QPS（CPU~75%）
- 安全水位：1.5万QPS
- 理论机器数：7台
- 最终机器数：10台（含冗余）
7. 注意事项
- 配置一致性保障
- 动态配置支持
- 回滚预案准备
- 云配额提前申请
- 日志与监控完整性
- 预估误差应急预案
参考文章：服务的容量规划：怎样才能做到有备无患？