配置选型：如何衡量业务量的指标
导读：本文摘自于阿里云MVP、驻云科技运维总监乔锐杰撰写的《阿里云运维架构实践秘籍》一书，本文将介绍衡量业务量的指标以及业务访问量与性能压力指标的转换，希望大家在云端配置选型上有所收获。
我们经常会遇到这样的问题，业务端反馈给后端一个在线用户数/活跃用户数，要求做架构规划时，需要用多少台服务器，大多数人都是一头雾水，不知道从何入手、如何去评估设计。最终，设计完全凭自己的感觉进行，用尽量多的服务器以及更多的成本预算，这就成了设计这个架构方案的“核心思想和精髓”。
同样，要部署一个Web类应用或一个数据库，具体要用什么样的服务器配置及宽带配置，相信大多数人同样还是一头雾水，仍是凭借感觉给出配置清单，用尽量高配的服务器及宽带，这就成了给出配置清单的“核心依据和精华”。事实上，在这些实践中，都是有技巧和章法的。
PV访问量、IP访问量、用户数、活跃用户数等都是常见衡量业务访问量大小的指标。通过合适的指标来评估及衡量业务量，是我们做容量配置规划的基础也是第一步。
一台Tomcat跑两亿PV的笑话
我们先来看一个真实的案例，某金融投资客户的业务跑在一台Tomcat上（注意，这里仅是一台4核8GB的ECS上搭建的Tomcat）。客户开展活动时，访问压力会增大，所以要求我们做好保驾护航及扩容工作。此时我们会慎重地询问客户活动时的访问压力是平时的多少倍。结果得知，活动期间可能引入的客户流量会暴增，初步估计是两亿PV。两亿PV的高访问量带给我的不只是震惊，更多的是触动，我开始思考客户的这个需求背后隐藏着的更深入的一些问题。后来，我也经常通过这个案例跟大家探讨业务真实访问压力与服务器性能配置的指标关系。
这个案例引人反思，也反映出当前企业普遍对容量配置规划没有概念：
不懂PV的概念，不懂2亿PV的量级是多大。
即使最近做活动有流量提升，但是仅有一台Tomcat跑着小业务的日常流量，突然要求其跑2亿PV的流量，这巨大的反差更是说明企业对业务流量没有清晰的认识。
衡量业务量的指标
衡量业务量的指标项有很多，比如，常见Web类应用中的PV、UV、IP。而比较贴近业务的指标项就是大家通常所说的业务用户数。但这个用户数比较笼统，其实和真实访问量有比较大的差距，所以为了更贴近实际业务量及压力，我们又把用户数的指标分成了活跃用户数、在线用户数以及并发用户数。常见衡量业务量级的指标汇总如表1所示。
表1 常见衡量业务量级的指标项
业务访问量与性能压力指标的转换
得到业务访问量的指标数据后，我们要将其转换成为系统压力的指标数据。这一步让抽象的业务访问量的指标数据，变成技术人员熟悉的性能压力指标数据，是容量配置规划的关键一步。
指标转换原理
我们对业务量数据没概念的原因在于这些都是业务的运营数据，无法转换成技术人员所熟悉的性能压力数据。这也是多数技术人员面对业务量数据时，对容量规划需要多少台服务器无从下手的根本原因，所以解决此问题的关键，就是把业务量的数据指标转换成技术人员熟悉的性能压力指标。这样在做架构规划设计、容量规划和成本预算时才能有章可循，从而使其思路更加清晰。
在配置实践中，业务访问量与性能压力指标的转换模型，特别是针对业务还处于前期需求规划期间的容量规划（业务系统还未研发上线，只能大体预估到未来可能的业务量，拿不到后端系统运行的实际性能压力状态数据），最为常见的做法就是把业务量的数据指标，最终转换成对系统的每秒请求数（某一秒内同时向服务器发送的请求数量，以下简称每秒请求数）这个指标，进而评估对应业务量，究竟产生了多少性能压力，最终设计出合理的架构，及要用多大规模的服务器及配置。值得注意的是，因为实际的业务特点不同，采用的开发语言及数据库技术也不同，所以这个转换以及要用多少规模的服务器及配置，只是一个估算的参考值，并不是最终的真实值。
如果业务还处于前期需求规划期间，业务量和性能压力的转换原理如图所示。
未上线业务量和性能压力的转换原理
在浏览器/服务器（Browser/Server）架构的Web类应用的实践中，常见的做法是把PV转换成每秒请求数，或者把用户数最终转换成每秒请求数。通常一般的做法都是将其转换成自己所熟悉的PV指标。
如果业务系统已经上线，生成指标转换的模型就要简单得多。一方面，当前业务系统有多少用户量及活跃用户量等业务数据，运营人员基本都能很直接地给出。另一方面，业务系统的运行性能状态也能通过监控很直接地体现出来。有了这两组数据，我们就能将用户量与性能压力进行转换对应，也能做出未来业务量下的容量规划等。对于业务系统已经上线的这种情况，业务量数据指标也不一定非要转换成对应的每秒请求数，可以根据实际情况选择合适的性能压力指标。当然，在条件允许的情况下，如果能对当前业务系统进行一次压力测试是最好的。压测结果能够让业务的用户访问数和实际系统可能出现的性能压力对应起来，特别是针对未来活动及可能出现的大流量的情况。
上线业务量和性能压力的转换原理
如果未来业务量增加，要做容量规划和成本评估，可以直接根据对应的业务指标将当前系统性能状态指标关联起来。常见的做法是使用简单的四则运算，比如，100万用户量，当前用了10台服务器，业务高峰期资源使用率是50%。如果变成200万用户量，至少要再加10台服务器。当然，在实际应用中，用户量增加对系统的压力可能不是呈线性级关系，而是指数级的关系，所以这个估算只是在做容量规划、成本预算规划时的主要参考值。最终需要看实际业务情况，同时还要结合监控看资源的具体使用时的性能情况。
通过以上对业务数据指标的转换可以看出，在做架构设计时，核心目的是前期在做规划的时候，能够看到未来的规模及容量大概要在一个范围区间，所以采用对应的估算也是尽量保障规划设计尽可能地接近真实情况，但这并不是绝对值，只是参考值。这也是接下来跟大家介绍指标换算模型时所要注意的，真实情况还要结合监控和压测实际来看。
性能指标转换计算模型实践
2013年，我面试过一家互联网公司的运维岗位，那是一家初创公司，起步规模不大。我非常清楚地记得面试官问过我一个问题：“一个500万PV的网站，大概要用多少台服务器？”这个问题是针对业务还处于前期需求规划状态提出的，考查的是根据业务规划如何做配置评估和成本预算。当时我回答这个问题的思路不是很清晰，只是说要看业务的复杂度等。这些年我一直在进行思考和总结，寻找将运营的业务数据跟系统的性能压力数据关联起来的方法，以便最终可合理地规划业务所需要的服务器资源量。
首先，我们要弄明白的是500万PV的业务访问量到底会对系统产生多大的请求压力。500万PV，即一天24小时中访问了业务页面500万次，如果用500万÷24小时÷60分钟÷60秒即可得出每秒的页面请求数，用这个结果表示对系统产生的请求压力值的话，那么得到的结果和实际情况将会有很大的偏差。因为实际的业务访问过程，比如，凌晨等业务低峰期，基本上没多少业务访问量。在实践中可以发现，一天中的80%业务请求量主要发生在40%的时间内，这成为我们计算PV值对应请求压力的重要依据。24小时的40%是9.6小时，即80%的请求发生一天的9.6个小时当中。基本与绝大多数的业务场景吻合，业务请求主要集中在白天，晚上则相对较少。
PV请求量计算模型如下：
每秒处理请求的数量=（80%×总PV量）/（24小时×60分×60秒×40%）
从而100万/500万PV请求量对应的计算结果为：
（80%×100万）/（24小时×60分×60秒×40%）= 23.1个请求/秒
（80%×500万）/（24小时×60分×60秒×40%）= 115.7个请求/秒
即服务器一秒能处理23.1个请求，就可以每天承受100万PV的业务量。服务器一秒能处理115.7个请求，就可以每天承受500万PV的业务量。
其次，在真实的业务场景下，有低谷也会有高峰，我们主要考虑高峰期的情况。假如一天中高峰期的请求量是平时请求的两倍或3倍（比如，电商之类的一些活动，高峰波动会更大，具体乘以多少根据业务情况而定），示例如下：
23.1个请求/秒×2倍= 46.2个请求/秒
23.1个请求/秒×3倍= 69.3个请求/秒
115.7个请求/秒×2倍= 231.4个请求/秒
115.7个请求/秒×3倍= 347.1个请求/秒
最终，如果服务器在一秒内能处理46.2～69.3个请求/秒，那么就能应对100万PV的业务请求量。
如果服务器在一秒内能处理231.4～347.1个请求/秒，那么就能应对500万PV的业务请求量。
业务指标转换计算模型实践
通过以上指标转换模型，我们可以知道对应的PV业务访问量具体对应多大的请求性能压力。这个数据，可以给我们做架构规划、容量规划、成本预算提供很好的参考。如果业务还处于前期需求规划期间，只是知道IP/用户数/活跃用户数/在线用户数/并发用户数这些业务访问指标，我们可以先将其转换成对应的PV业务访问量，进而折算成每秒请求数，或者先转化为并发用户数，再折算成每秒请求数。
实践案例1：IP访问量向PV访问量的转换计算模型
虽然网站的IP访问量、PV访问量等明细数据信息，可以通过CNZZ等网站流量统计分析出来（需要在网站页面安装插件，主要分析统计七层客户端请求数据），但这里还是简要地介绍一下，主要是想让大家理解在实践背后，怎么估算自己业务的实际性能压力值。IP的访问量转到PV访问量，其实转换的核心在于Web网站的业务类型，不同业务特性的计算模型实践总结如表2所示，仅供读者参考。
表2 不同业务特性的计算模型
值得注意的是，假设每个用户都有独立的IP，则IP访问量等于活跃用户量。但在实际用户场景中，活跃用户量是大于IP访问量的（偏差一般为1～2倍）。这是因为很多用户的公网局域网通过SNAT方式访问公网，这时候不同用户访问系统，其实系统中识别的只是一个IP。但由于根据不同Web的业务形态，将其转换成PV量，就考虑到2～5倍、5～10倍、10～30倍，甚至更高倍数的冗余。所以在这种高倍数估算的前提下，我们就会认为IP访问量约等于活跃用户量。
实践案例2：用户数向并发用户数的转换计算模型
一般指业务系统的注册用户数，这个业务数据其实是“死”的。比如，注册了10万个用户、100万个用户，最后没人访问业务系统，那就没有任何意义了。假如一个10万用户量的Web类用户，一天活跃用户数是1万人，同时在线的人员是1000人，那么这表示在最高峰期，有1000人同时登录了系统，但这并不表示实际服务器承受的压力。因为服务器承受的压力还与具体的用户访问模式相关，比如，这1000人同时使用系统的时候：
可能有40%的用户：在浏览系统内容（注意，停留页面“看”这个动作是不会对服务端产生任何负担的，并不同于数据库查询的操作）。
可能有20%的用户：在填写复杂的表格（填写过程并不对服务器产生请求压力，只有在“提交”的时候才会向服务端发送请求）。
可能有20%的用户：在挂机（也就是什么都没有做，也不会对服务器产生请求压力）
最后剩下的20%用户：在页面中做点击、跳转、提交等操作，可能只有这种情况下才实际对服务器产生请求压力。
计算模型参考：
用户数×业务因子（10%～30%）=活跃用户数
活跃用户数×业务因子（10%～30%）=在线用户数
在线用户数×业务因子（10%～30%）=并发用户数≈每秒请求数
本文摘自于《阿里云运维架构实践秘籍》，经出版方授权发布。
更多关于配置选型的问题，推荐阅读《阿里云运维架构实践秘籍》。欢迎大家在留言中讨论交流对衡量业务量指标的看法以及疑惑。
更多精彩回顾
书讯 | 6月书讯 （上）| 初夏已至，书香有约，六月宜静心读书
书讯 | 6月书讯 （下）| 初夏已至，书香有约，六月宜静心读书
上新 | 周志华领衔撰写，历时4年，宝箱书问世！
书单 | 创建字节跳动之前，张一鸣读过哪些硬核技术书？
干货 | G1垃圾回收算法概述