概述
正如飞机在起飞前,机长、副机长要过一遍checklist检查,确认没问题了才能起飞。楼主也整理了一个系统容量现状checklist,方便对照检查。本文搭配架构师必备:如何做容量预估和调优,食用更佳。
作为架构师,不要觉得系统容量是运维工程师才关心的问题,而应当对系统容量现状做到了如指掌。这样才能知道系统的瓶颈在哪,哪些优化是要优先做的,以及为了应对活动期间突发的流量,做多少扩容。
本文分为2大部分,一是资源使用率,二是业务指标。
资源使用率
服务实例
- 实例个数、每个实例server的工作线程个数、MQ消费组线程个数
- QPS峰值
- 接口响应时间:平均、95分位、99分位、最大值
- CPU使用率峰值
- 报错数量/秒
- JVM堆内存使用率峰值
- GC回收时间
-
MySQL
分库数量、分表数量、从库个数、路由规则
- QPS峰值、TPS峰值、读写比例
- CPU使用率峰值
- 磁盘使用率
- 有无热点、数据倾斜
- 行总数
- 主从复制/同步延迟ms
- 慢查询数量/秒
-
Redis
实例个数、集群方式
- QPS峰值、TPS峰值、读写比例
- CPU使用率峰值
- 内存使用率峰值
- key总数
-
HBase
实例个数、region个数
- CPU使用率峰值
- 磁盘使用率
- 行总数
- compaction时间段
-
ElasticSearch
实例个数、分片shard个数、路由规则
- 文档document个数
- CPU使用率峰值
- 磁盘使用率
-
消息队列
实例个数、分片partition个数
- 消息TPS峰值
- 消费堆积数量
- CPU使用率峰值
-
业务指标
核心流程的业务指标
每个系统都不一样,需要根据实际情况定义业务指标。如:
xxx成功率
- xxx失败率
- xxx个数、次数
- xxx时长
- xxx参与人数
-
状态机流转情况
如图所示,示例的状态机流转情况如下: 流转方向:只能从1流向2,不能从2流向1
- 前置状态:只能从2或3流向4,不能从1流向4
- 中间态停留时长:2、3、4是中间状态,不应当长时间停留,否则认为是卡住了
- 终结状态:5(成功)和6(失败)是终结终态,最终都会变成5或6
因此,需要关心的业务指标如下:
- 各状态的个数
- 成功率:成功终结状态的比例
- 整个流程的时长
- 卡在中间态的个数、时长