服务化系统容量评估和性能保障
1 目标
1.1 非功能质量需求的概述
通过参考技术评审指标,保证系统架构设计满足用户和系统对非功能质量的需求:
核心非功能质量:
| 核心质量 | 描述 |
|---|---|
| 高性能 | 运行效率高,性价比高 |
| 可用性 | 持续可用性,缩短宕机时间,出错恢复,可靠性 |
| 可伸缩 | 垂直伸缩,水平伸缩 |
| 可扩展 | 可插拔,组件重用 |
| 安全性 | 数据安全,加密,熔断,防攻击 |
其他非功能质量:
| 其他质量 | 描述 |
|---|---|
| 可监控性 | 快速发现,快速定位,快速解决 |
| 可测试性 | 可灰度,可预览,可Mock,可拆解 |
| 鲁棒性 | 容错性,可恢复性 |
| 可维护性 | 易于维护,监控,运营,扩展 |
| 可重用性 | 可移植性,解耦 |
| 易用性 | 可操作性 |
1.2 非功能质量需求的具体指标
主要分为4部分:应用服务器、数据库、缓存和消息队列。
1.2.1 应用服务器
应用服务器是服务的入口,请求流量从这里进入系统,数据库,缓存和消息队列的访问量取决于应用服务器的访问量,对应用服务器的访问量进行评估至关重要,应用服务器主要关心每秒请求的峰值,请求响应时间等指标,通过这些指标可以评估需要的应用服务器资源的数量。
| 指标分类 | 部署结构 | 容量和性能 | 其他 |
|---|---|---|---|
| 1 | 负载均衡策略 | 每天请求量 | 请求的内容是否包含大对象 |
| 2 | 高可用策略 | 各接口访问峰值 | GC收集器的选型和配置 |
| 3 | IO模型(NIO/BIO) | 平均请求相应时间 | |
| 4 | 线程池模型 | 最大请求相应时间 | |
| 5 | 线程池线程数量 | 在线用户量 | |
| 6 | 是否多业务混布 | 请求大小 | |
| 7 | 网卡IO流量 | ||
| 8 | 磁盘IO负载 | ||
| 9 | 内存使用情况 | ||
| 10 | CPU使用情况 |
1.2.2 数据库
根据应用层的访问量和访问峰值,计算出需要的数据库资源的QPS,TPS,每天的数据总量等,由此来评估所需数据库资源的数量和配置,部署结构等。
| 指标分类 | 部署结构 | 容量和性能 | 其他 |
|---|---|---|---|
| 1 | 复制模型 | 当前数据容量 | 查询是否走索引 |
| 2 | 失效转移策略 | 每天数据增量(预估容量) | 有没有大数据量的查询 |
| 3 | 容灾策略 | 每秒读峰值 | 有没有多表关联,关联是否用到索引 |
| 4 | 归档策略 | 每秒写峰值 | 有没有使用悲观锁,是否可以改造成乐观锁,或者是否可以利用数据库内置行级锁 |
| 5 | 读写分离策略 | 事务量 | 事务和一致性级别 |
| 6 | 分库分表(分片)策略 | 使用的JDBC数据源类型,连接数等配置 | |
| 7 | 静态数据和半静态数据是否使用缓存 | 是否开启JDBC诊断日志 | |
| 8 | 有没有考虑缓存穿透压垮数据库的情况 | 有没有存储过程 | |
| 9 | 缓存失效和缓存数据预热策略 | 伸缩策略(分区表,自然时间分表,水平分库分表) | |
| 10 | 缓存失效和缓存数据预热策略 | 水平分库分表实现方法(客户端,代理,Nosql) |
1.2.3 缓存
根据应用层的访问量和访问峰值,通过评估热数据占比,计算出的缓存资源的大小,存取缓存资源的峰值,由此来计算所需缓存资源的数量和配置,部署结构等。
| 指标分类 | 部署结构 | 容量和性能 | 其他 |
|---|---|---|---|
| 1 | 复制模型 | 缓存内容的大小 | 冷热数据比例 |
| 2 | 失效转移 | 缓存内容的数量 | 是否有可能缓存穿透 |
| 3 | 持久策略 | 缓存内容的过期时间 | 是否有大对象 |
| 4 | 淘汰策略 | 缓存的数据结构 | 是否使用缓存实现分布式锁 |
| 5 | 线程模型 | 每秒读峰值 | 是否使用缓存支持的脚本 |
| 6 | 预热方法 | 每秒写峰值 | 是否避免了Race Condition |
| 7 | 分片Hash策略 | 缓存分片方法(客户端,代理,集群) |
1.2.4 消息队列
根据应用层的访问量和访问峰值,计算需要消息队列传递的数据内容和数据量,计算出的消息队列资源的数量和配置,部署结构等。
| 指标分类 | 部署结构 | 容量和性能 | 其他 |
|---|---|---|---|
| 1 | 复制模型 | 每天平均数据增量 | 消费线程池模型 |
| 2 | 失效转移 | 消息持久的过期时间 | 分片策略 |
| 3 | 持久策略 | 每秒读峰值 | 消息的可靠投递 |
| 4 | 每秒写峰值 | ||
| 5 | 每条消息的大小 | ||
| 6 | 平均延迟 | ||
| 7 | 最大延迟 |
1.3 典型的技术评审提纲
- 现状.业务背景和技术背景
- 需求.业务需求和性能需求
- 方案描述
- 概述
- 详细说明
- 中间件架构(应用服务器,数据库,缓存,消息队列)
- 逻辑结构(模块划分,通信,信息流,时序)
- 数据架构(数据结构,数据分布,拆分策略,缓存策略,读写分离策略,查询策略,数据一致性策略)
- 异常处理,容灾策略,灰度发布,上线方案,回滚方案
- 性能评估
- 单机并发量
- 单机容量
- 按照预估性能需求,预估资源数量(应用服务器、缓存、存储、队列等)
- 伸缩方式
- 单机并发量
- 方案的优缺点
- 方案对比
- 风险评估
- 工作流评估
2.性能评估参考标准
通用标准
- 容量按照峰值5倍冗余计算
- 分库分表后的容量一般可存储30年的数据
- 第三方查询接口5000 QPS
- 单条数据库记录占用大约1K空间
Mysql
- 单端口读:1000 QPS
- 单端口写:700 TPS
- 单表容量:5000万条
Redis
- 单端口读:4万 QPS
- 单端口写:4万 TPS
- 单端口内存容量:32G
Kafka
- 单机读:3万 QPS
- 单机写:5000 TPS
DB2
- 单机读峰值:20000
- 单机写峰值:20000
- 单表容量:1亿数据
3.测试工具
- ab: 针对HTTP实现的服务进行性能压测工具
- jmeter: 基于Java的性能压力测试
- mysqlslap: Mysql自带的一款性能压测工具, 通过模拟多个并发客户端访问Mysql来执行压力测试
- sysbench: CPU性能测试、线程锁性能测试、磁盘随机IO性能测试、内存性能测试
- dd: 测试磁盘顺序IO的存取速度
- LoadRunner: 专业的性能和负载压力测试
- hprof: JDK自带的分销内存堆和CPU使用情况的命令行工具