在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 背景
数字家庭管理平台两个质量需求。
- 1.第三方系统信息查询，复位重启接口频繁调用。
- 2.ihdmgr，apmgr进行分布式部署，日志检索耗时费力。
3.2 目标数据量级
- 智能网关，机顶盒，智能组网设备合计800万，平均每天增长1.2万。
- 平均每天装，撤，拆，移工单2.4万单，下单集中在8:00~19:00，占比80%。
3.3 量级评估标准
- 通用标准
容量：按照峰值的3倍进行冗余设计。
业务开通容量：时效性较强，按照2年计算，转储设计。
第三方查询接口：吞吐量为1000/S.
- mysql
单端口读：1000/S
单端口写：700/S
单表容量：5000万条。
- Redis
单端口读：40000/S
单端口写：40000/S
单端口内存容量：32GB
- Kafka
单机读：30000/S
单机写：5000/S
- web 服务器
请求量的峰值：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台。
四. 常用的系统层性能指标参考标准
- 寄存器和内存
- 寄存器，L2,L3，内存，分支预测失败，互斥量加锁和解锁等耗时为纳秒级别
- 内存随机读取可达30万次/s，顺序读取可达500万次/s
- 内存每秒可读取GB级别的数据。
- 读取内存中1MB的数据为250ns，为亚毫秒级别。
- 硬盘
- 普通SATA机械盘IOPS能达到120次/S
- 普通SATA机械盘顺序读取数据可达100MB/S，读取1MB 数据20ms
- 普通SATA机械盘随机读取数据可达2MB/S
- 普通SATA机械盘旋转半圈需要3ms
- 普通SATA机械盘寻道需要3ms
- 普通SATA机械盘寻道后开始读取数据，读取一次数据真正耗时2ms
- fusionIO卡（一种高的ssd硬盘套件）可达到百万级别的IOPS,
- 高端机器如ibm，华为等服务器上的高端存储设备，每秒GB级别的数据读取，相当于内存的读取速度。
- 固态硬盘访问延迟：0.1-0.2ms，和内存速度相当。
- 网络IO
- 常见千兆网卡传输速度为1000Mbit/S, 即128MB/S
- 千兆网卡读取1MB数据，10ms。
- 数据库
- 通常读取一条记录在毫秒级别，短则几毫秒，大于500ms一般为超时。
- mysql在4核心，256G内存中性价比最好，继续垂直扩展由于体系结构限制，成本开始增加，性价比开始降低。
- IDC
- 同一机房网络来回：0.5ms
- 异地机房来回：30~100ms
- 同一机房RPC服务调用为几个毫秒，500ms为超时。
- 网站：
- UV:每日一共有多少用户来访，用cookie session跟踪。
- 独立ip访问：每日有多少独立ip来访，同一个局域网可以看成一个ip
- pv：每日单独用户的所有页面访问量，如果每日uv为50000 000，那么每秒平均在线人数为：50000 000/24/60/60=578人。如果每秒都做一次查询，则需要一个能承载578/S吞吐量的机器。
- 组合计算：
- 普通机械盘：3ms 旋转 3ms 寻到 2ms读取延迟=8ms
- 普通sata机械盘每秒随机读取：1000ms/8ms= 125次 IOPS.
- IOPS代表每秒可随机寻址次数，随机读取速度取决于数据如何存放，如果按照块存放，每块4KB，每次读取10块，那么随机读取速度为：10*4KB*125次/S=5MB/S
- 一次读取内存时间：1000ms/30万次/S=3ns
- cpu速度=10倍*内存速度=100倍*IO速度
