软件系统性能常见方法论? 在IT行业的发展过程中,先有传统行业,后出现了互联网行业传统行业的特点为:业务抽象度高,重用率高,流程复杂,中心化管理互联网行业的特点为:业务水平,垂直拆分,模块化,职责单一,功能简单,敏捷交付,非功能性质量要求高,我来为大家科普一下关于软件系统性能常见方法论?下面希望有你要的答案,我们一起来看看吧!
在IT行业的发展过程中,先有传统行业,后出现了互联网行业。传统行业的特点为:业务抽象度高,重用率高,流程复杂,中心化管理。互联网行业的特点为:业务水平,垂直拆分,模块化,职责单一,功能简单,敏捷交付,非功能性质量要求高。
通常软件架构设计分为需求分析整理,概要设计,详细设计三个阶段,每个阶段任务如下:
一. 架构权衡分析法(ATAM)
架构权衡分析法(Architecture Tradeoff Analysis Method,ATAM)为行业通用的实践方法,该方法揭示架构满足特定质量目标的情况,使得我们认识到目标与质量之间的权衡和制约。通用的非功能质量指标包括:高可用,高性能,可伸缩,可扩展,安全性,稳定性,可维护性,可测试性,健壮性等。
非功能质量指标 |
描述 |
高性能 |
运行效率高,性价比高,通常指单节点吞吐量和响应时间 |
高可用 |
持续可用性,缩短宕机时间,出错恢复,可靠性 |
可伸缩性 |
垂直,水平伸缩 |
可扩展性 |
可插拔,组件重用,新业务,新功能叠加 |
安全性 |
数据安全,加密,熔断,防攻击 |
可监控性 |
快速发现,定位和解决问题 |
可测试性 |
可灰度,可预览,可Mock,可拆解,QA测试,准生产测试 |
鲁棒性 |
容错性,可恢复性 |
可维护性 |
易于维护,监控,运营和扩展 |
可重用性 |
模块化,可移植性,解耦 |
易用性 |
可操作性 |
非功能性质量需求的具体指标针对不同的系统主要分4部分:应用服务器,数据库,缓存和消息队列。
1. 应用服务器
序号 |
部署结构 |
容量性能指标 |
1 |
负载均衡策略 |
每天请求量 |
2 |
高可用策略 |
各接口访问峰值 |
3 |
I/O模型 |
平均的请求响应时间 |
4 |
线程池模型 |
最大的请求响应时间 |
5 |
线程池中的线程数量 |
在线用户量 |
6 |
是否多业务混合部署 |
请求的大小 |
7 |
网卡的IO流量 | |
8 |
磁盘的IO负载 | |
9 |
内存的使用情况 | |
CPU的使用情况 |
2. 数据库
关注吞吐量,每天数据总量
序号 |
部署结构 |
容量性能指标 |
1 |
复制模型 |
当前的数据容量 |
2 |
失效转移策略 |
每天的数据增量 |
3 |
容灾策略 |
每秒的读/写峰值 |
4 |
归档分离策略 |
每秒的事务量峰值 |
5 |
分库分表策略 |
查询是否走索引 |
6 |
静态数据是否启用缓存 |
有没有大数据量的查询和范围查询 |
7 |
穿透缓存方案 |
有没有多表关联,关联是否用到索引 |
8 |
缓存预热策略 |
有没有使用悲观锁,是否可以改为乐观锁,行级锁。 |
9 |
事务的一致性级别 | |
10 |
JDBC数据源类型及连接数配置,诊断日志是否开启 | |
11 |
有没有存储过程 | |
12 |
伸缩策略(分区表,自然时间分表,水平分库分表)水平分表的实现方法(客户端,代理,nosql) |
3. 缓存
根据应用层的访问量和访问峰值,通过评估热数据的占比,计算缓存资源的大小并估算缓存资源的峰值,由此来计算缓存资源的数量,部署结构,高可用方案等。
序号 |
部署结构 |
容量和性能指标 |
1 |
复制模型 |
缓存内容大小 |
2 |
失效转移 |
缓存内容的过期时间 |
3 |
持久策略 |
缓存的数据结构 |
4 |
淘汰策略 |
每秒的读、写 峰值 |
5 |
线程模型 |
冷热数据比例 |
6 |
预热方法 |
分布式锁 |
7 |
哈希分片策略 |
缓存分片方法(客户端,代理,集群) |
8 |
是否有大对象 | |
9 |
是否有可能缓存穿透 |
4. 消息队列
序号 |
部署结构 |
容量和性能指标 |
1 |
复制模型 |
每天平均的数据增量 |
2 |
失效转移 |
消息持久的过期时间 |
3 |
持久策略 |
每秒的读、写峰值 |
4 |
每条消息大小 | |
5 |
平均延迟 | |
6 |
最大延迟 | |
7 |
消费者线程池模型 | |
8 |
哈希分片策略 | |
9 |
消息的可靠投递 | |
10 |
消费者的处理流程和持久机制 |
二. 技术评审提纲
1. 业务需求:要改造的内容,要实现的新需求
2. 性能需求:预估系统容量(预估系统调用量平均值,平均响应时间),安全性,可伸缩性。
1.概述:一句话概括方案亮点:双写,迁移,主从分离,分库分表,扩容,归档,接口改造。
2.详细说明:结合各种视图(UML,概念图,框图)表明改造方案,突出变动的地方。
3.性能评估
三. 系统评估案例
备注:如下数据基准仅做案例演示。
3.1 背景
数字家庭管理平台两个质量需求。
3.2 目标数据量级
3.3 量级评估标准
容量:按照峰值的3倍进行冗余设计。
业务开通容量:时效性较强,按照2年计算,转储设计。
第三方查询接口:吞吐量为1000/S.
单端口读:1000/S
单端口写:700/S
单表容量:5000万条。
单端口读:40000/S
单端口写:40000/S
单端口内存容量:32GB
单机读:30000/S
单机写:5000/S
请求量的峰值:200/S
3.4 方案
方案一. 最大性能方案
无法预估第三方的调用行为,假设提供最快的响应时间,最大的服务性能。
提供RESTful 服务来查询终端信息。
提供RESTful服务来重启对应终端。
按照1%的终端用户存在潜在查询需求,且集中在9:00-19:00 这10个小时内。冗余按照3倍设计。
(800w*0.01)/(10*60*60)*3=2.23*3=7/s
mysql单端口完全够用。
复位重启后,10条参数需要重新下发,1%的终端用户存在潜在复位重启需求,且集中在9:00-19:00 这10个小时内。冗余按照3倍设计。
(800w*0.01*10)/(10*60*60)*3=22.3*3=70/s
mysql 单端口完全够用。
当前800万用户,1%复位重启,每个用户下发10条参数,3倍冗余,单表容量5000万,2年后下发参数条目数及所需表数量计算如下:
(800w*0.01*365*2年)*10条*3倍=17亿条/0.5亿=34张。
根据以上读写吞吐量评估,如果读写分离,主从部署,需要1主1从,如若考虑主备,则需要2主2从。34*2=68张表,考虑将来端口扩展不拆分数据库,尽量设计更多的库,比如使用16个库。设计结果:2端口*16库*2表。
为了提升查询效率,需要redis缓存活跃终端的基本信息,定义近一天和平台有联系的终端(40%)为活跃终端,缓存24小时,每条终端信息为1KB, 冗余3倍设计,缓存大小计算如下:
800w*0.4*1KB=3.2GB*3=9.6G.
1台机器32G,读写满足5000/S, 所以设计结果为1台。
根据数据库读写7/S, 70/S的峰值计算,单台应用服务器即可,选择两台可避免单点故障。
设计结果2台。
所以最大性能设计方案最终需要服务器:
数据库2台 缓存服务器1台 应用服务器1台=4台。
方案二. 最小资源方案
请求量暂时无法评估,最小资源方案可节省成本,目前测算单台容量足够承载。
数据库1台 应用服务器1台=2台。
四. 常用的系统层性能指标参考标准