开发者学习笔记【阿里云云原生助理工程师认证（ACA）课程：消息队列和应用工具产品体系-14-容量规划及不同模式的适用场景景】
课程地址：https://edu.aliyun.com/course/3112075/lesson/19047
消息队列和应用工具产品体系-14-容量规划及不同模式的适用场景
内容介绍
一、并发模式，RPS模式定义
二、容量规划的基本方法
三、并发模式、 RPS 的适用场景
四、如何确定压测时的并发数和 TPS 上限
一、并发模式，RPS模式定义
在进行性能测试的时候，传统的方法是从客户端的视角出发，用并发虚拟用户数进行衡量系统的性能。
通过响应时间来衡量系统的性能(站在客户端视角)，一般适
适用于一些网页站点例如首页、H5的压测。
在并发模式下，常用的技术指标是并发用户数和响应时间。
并发用户数：简称 VU ，指的是现实系统中操作业务的用户个数。
在性能测试工具中，一般会用虚拟用户来模拟实际的用户，在这里需要注意的是“并发用户数”和“注册用户数”以及“在线用户数”是有很大区别的。
具体介绍：
“并发用户数”一定会对服务器产生计算压力；
“注册用户数”一般指数据库中存在的用户数，并不是真正活跃的用户；
“在线用户数”虽然指的是活跃用户，但在大部分时间里，因为思考、等待、阅读等原因，大部分时间只是挂在系统上，对服务器并不产生直接的计算压力。
响应时间：简称 RT ，指业务从客户端发起请求到客户端收到结果时间。可以称之为高并发模式下性能压测最重要的技术指标。
性能压测的另外一种模式是“ RPS 模式”。
RPS（Requests Per Second） 模式:
主要是为了直接衡量系统处理业务的能力TPS(站在服务端视
角)
RPS模式是站在服务端的视角，为了直接衡量系统处理业务的能力 TPS而设计的一种压测模式;其中业务的处理能力一般用（Transaction Per Second 每秒事务数）来表示，简称为 TPS ，是衡量系统性能的一个非常重要的指标，而 RPS 指的是客户端每秒发出的请求数，在相对简单的业务中，每个发出的请求对应到后端需要执行的业务数量是一定的；所以大部分情况下 RPS 和 TPS 可以等价或者具有简单的固定比例关系，因此在 RPS 模式下，通过被压缩端需要达到的 TPS，设置等量的 RPS，来测试排除其他影响因素之后的服务是否可以达到设计的性能指标。
RPS 模式应用场景主要是一些动态的接口 API，例如登录、提交订单等等。
在系统的实际运作中， VU 和 TPS 之间也有相对应的逻辑关系，举例说明：
TPS 是每秒事务数，但是事务是靠虚拟用户做出来的。
假如一个虚拟用户在一秒内完成了一笔事务，这个时候 TPS 是1，而 VU 也是1，同时 RT 为1秒；
如果某笔业务的响应时间是1毫秒，一个用户在1秒内能完成1000笔事务，TPS 是1000，而 VU 还是1，RT 变为1毫秒；
如果某笔业务的响应时间是1毫秒，一个用户在1秒内只能完成一笔事务，如果想达到1000的 TPS 至少需要1000个虚拟用户。
因此可以说一个用户可以产生1000 TPS ，1000个用户也可以产生1000个 TPS，差别就在响应时间 R T的快慢上，一般来说 VU、TPS、RT、RPS 他们之间的关系，如公式所示：
TPS：每秒执行的事务数。其计算公式为：
TPS（每秒事务数）≈ RPS（每秒请求数）
RPS = VU（虚拟用户数）/ RT（响应时间）
二、容量规划的基本方法
容量规划中的平衡状态
1、容量规划的目的
• 追求链路上的所有服务都处于平衡状态
• 可以理解为，为了保证所有服务都可以达到最大的工作效率，运维人员的调配各个服务之间的资源分配，保证所有服务都在工作，也不会存在服务超载。
在现在的企业及应用中，应用的负载量及计算压力越来越重，应用的用户并发量也变得越来越大，因此应用所在的运行环境、所需要的计算资源数量以及成本也越来越高，在这种情况下如何对计算资源做到精细的分配，做到在能满足应用设计负载的前提下，尽量降低 IT 计算资源的成本，就成了系统运维中的一个重要工作。
2、平衡状态图例解释
• A，B，C节点在同一条链路上。
• 虽然节点的处理速度不同，但是在平衡状态下，节点之间的RPS是相同的。
• 平衡状态下，节点之间的RT和节点的个数成正比.
• 平衡状态和VU没有直接的关系
在容量规划中，一个比较重要的概念就是服务的平衡状态。
平衡状态是指系统中的物体的平均数量=物体离开系统的平均速度，和每个物体在系统中停留的平均时间的成绩。
举例讲解：
假设现在有一条生产流水线，流水线上有100个工人 ，为了简化问题，我们认为100个工人的生产效率是完全一致的，因此，工人的工作效率只与工作的复杂度有关，同时在流水线上有3道工序，分别
如下图所示：
节点 A、B、C 三个工序必须按照顺序进行执行
节点 A 工序中，工人完成工作的平均耗时（RT A=0.5″）；
节点 B 工序中，工人完成工作的平均耗时（RT B=3″）；
节点 C 工序中，工人完成工作的平均耗时（RT C=1.5″）。
在这种情况下从整体的角度可以进行分析，节点 A、B、C 分别需要安排多少个工人，才能使工作流水线达到最大的产能。
整条流水线的总工时消耗 =0.5+3+1.5″为5秒，那么我们就可以得到流水线的产能=100（工人）/5″=20件/秒。根据流水线的总产能再乘以每个节点的耗时我们就可以得出每个节点所需要的工人数量。分别是：
A工序20*0.5=10人
B工序20*3=60人
C工序=20*1.5=30人
在这种状态下所有的工人都有事可做，也不会存在工人忙不过来的情况，这种情况我们称之为平衡状态。
经过以上推倒，我们还可以得到以下结论：
（1）在平衡状态下，所有节点的 RPS 必然是一样的，而节点之间的RT 和节点的个数是成正比的，平衡状态和 VU 并没有直接关系。
（2）任何节点的 RT 都会影响整体系统的 RPS，进而会影响资源在节点之间的分配关系。
三、并发模式， RPS 模式的适用场景
在实际的生产环境中影响 RT 的外部因素非常多
例如用户思考时间，访问资源是否重合，第三方资源响应时间等。同时系统的负载率 TPS 的高低也会对 RT 产生影响。
为了能使系统达到平衡状态，就需要对系统的整体和具体模块分别进行各种条件下的性能压测，以此获得相对比较精准的模块 RT 值。
在这种情况下，并发模式与 RPS 模式压测各有各自擅长的适用场景。
并发模式更加适合于对系统进行定性的分析，通过设置不同的 VU 和外部影响因素，观察 RT 的变化。比如：帮助定位性能瓶颈，单接口的性能基线沉淀；而 RPS 模式在对系统做定量的分析时则有杰出的表现，通过设置各种影响单模块计算难度的因素，找出模块最佳的负载率，并且有针对性的对性能瓶颈进行优化和对比。
并发模式的难点在于始终都受制于不稳定的、难以模拟的、难以预测的接口 RT 的准确性拟真。因此，通过并发模式指导用为容量规划的结果，往往准确度会偏差比较大。
RPS 模式下的容量规划，则抛弃了并发模式下的模拟接口 R T的方式，而是改为了对每个模块通过过往的历史数据，生成流量经验模型，再通过流量经验模型估算出未来的一个时间内的最大流量，在压测的实施时，压测的主题也是 RPS，同事依照流量模型的预估值进行压测，从而获得最合适的节点数量。因此，在 RPS 模式下，容量规划的难点就在于模型的准确性评估和预测。总之，这两种模式在技术的难点上来讲并发模式的 RT 时间预估相对于 RPS 模式下的流量模型建立来说显得难度更大一点，掌控度也更低一点。
四、如何确定压测时的并发数和 TPS 上限
通过已有系统规划压测VU:
（1）可以选择系统的高峰时刻，在一定时间内使用系统的人数，这些人数就可以认为是在线用户数。并发用户数一般可以取在线用户数的10%。
（2）例如：在半小时内，使用系统的用户数为10万，那么取10%（即1万）作为并发用户数。
一般的情况下：
（1）大型系统做压力测试时：10000-50000个用户做并发。
（2）中小型系统做压力测试时：5000个用户做并发比较常见。
通过已有系统规划压测TPS:
（1）可以选择高峰时刻内在一定的时间，（如3-10分钟），获取系统的总业务量，计算这段时间内每秒完成的业务笔数，然后将这个数据乘以2-5倍作为峰值的 TPS。
（2）例如峰值3分钟内处理订单18万笔，则平均 TPS 是1000，这样峰值的 TPS 就可以设置为2000-5000。
对于新系统来说由于没有历史数据来作为参考，所以建议通过业务部门来进行容量上限的评估。
容量规划总结：针对服务器端的性能描述一般以 TPS 为主，并发用户数为辅，来衡量系统的性能。如果必须要用并发用户数来衡量的话，则需要一个前提，那就是要明确交易在多长时间内完成。因为在系统负载不高的情况下，将等同于交易时间的思考时间加入到串联链路中时，系统的并发用户数基本可以增加一倍。因此，用并发用户数来衡量系统的性能并没有太大的意义；同样的如果系统间的吞吐差别很大，那么同样并发下的 TPS 差距也会很大。所以建议开发者在做性能测试的时候，不要设置过长的思考时间，以最坏的情况对服务器进行施压。
总体而言，容量规划是一个非常大的课题，阿里巴巴2013年构件了一套基于线上全链路压测的规划系统，逐步替代之前的单应用、单接口这种低效的容量评估手段，其过程也是非常曲折的。
