在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机械盘寻道后开始读取数据，读取一次数据真正耗时2msfusionIO卡（一种高的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来访，同一个局域网可以看成一个ippv：每日单独用户的所有页面访问量，如果每日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=3nscpu速度=10倍*内存速度=100倍*IO速度,
