上一篇讲的是《性能优化的常见模式及趋势》，今天接着讲集中常见的压测模型。
通过上一章我们大概知道了性能优化的一些招式，但是怎么发现有性能问题，常见的模式还是需要压测。下面列举进行列举。
压测模型抽象
可以把压测模型抽象为上图的模型。
压测环境准备
压力机资源
被压测系统
依赖资源（压测数据，第三方依赖）
压测策略准备
压测需要达到的目标（比如期望达到的QPS，稳定性要求等）
压测场景（业务场景选取、组合）
压测策略（逐步加压、脉冲、并发量等）
压测执行闭环
压力机压测
分析程序收集压测数据（RT，QPS/TPS，成功率，错误，内存，IO等）专业的工具基本涵盖
分析压测报告
确定优化计划
反馈到压测系统或者调整压测策略
线下压测模型
此类压测模型最多，也是最容易实现的。有技术实力、资源的公司，开发环境和压测环境是隔离的。
图中举例的是分布式系统结构的压测拓扑图，实线是同步调用，虚线是消息类调用。
此类压测方式，最容易操作，有如下优点：
可以实现快速压测
压测场景可以自由自定
可以进行稳定性测试或者链路性性能回归
但是从执行来看缺点也很多
仿真度不高
环境部署复杂
多个压测任务一般不能并行
环境问题永远困扰你
比如仿真度问题，环境问题永远困扰你
依赖系统可能缺失
数据可能确实
使用的机器，网络，DB都和线上不一样。
服务化后，线上各应用是集群部署，比如A可能是1000台，B可能是100台，是10：1的比例关系，但是线下一般是1：1，这个比例是失真的。
线上引流压测模型
此类压测模式是使用比较多的高仿真压测。
有如下优点：
真是的业务场景测试
可以按需缩容
可以快速回退
缺点也有：
对链路节点压测不了（DB流量可能不够，网络节点等）
很难进行超出业务流量的压测
很难评估链路性能
线上引流压测是不错的压测模式，关键技术有
流量的控制能力
可以按需切换流量，web层诸如使用ngnix，服务和服务调用之间也需要按需切换。如果为了是自己对流量控制能力更强，都建议在需要控制的各层，加入代理层，这个代理层可以实现路由算法，通过调整路由算法，到达控制的目的。比如可以扩展ngnix的模块，如果是dubbo，可以扩展服务调用的寻址逻辑。
服务监控能力
如何在线上压测快速识别压测情况，如果压测是单台机器，登陆一台机器当然可以确认情况，但是如果有一堆机器，怎么办？必须自动化掉，监控核心指标。
服务化后的系统使用普通的线上压测模式很难发现链路问题，所以现在有如下进阶的压测模式，外部也应该分享过。
线上全链路压测模式
现在阿里体系，已经实现了此类压测模式，用于对大促等爆发流量进行模拟。使用完全真实的线上环境，进行高仿真的线上压测，可以按照线上真实的容量部署情况进行链路压测。
优点：
高仿真
按需的压测流量（可以构造比日常容量大得多的请求量）
缺点：
实施成本很高，一般的公司可以不这么玩，前面的方式已经够了。
其他
这几种模式主要就是现在使用的模式了，可能有变体，我想不会差的太大。
压测的时候还有些注意点，诸如小心压力机的瓶颈；现在使用的比较多的工具是jmeter等。这些就不详解了。
作者：征途小丘，陈显铭，蚂蚁金服技术专家，分享性能优化的常见模式及趋势
原文链接：性能优化之几种常见压测模型及优缺点
相关资源：机器学习模型性能测试（R,python）