---

1 导论

本章的主要内容是掌握架构设计必知必会之资源估算的一些知识。落在项目上，就是对订单系统进行资源估算。我们在估算之前要对一些系统性能的基本指标进行衡量。当然啊最理想的是在实际部署应用环境进行服务端的性能测试。这样得到的指标呢是更适合整个项目的资源估算的。然后我们去学习什么是资源估算，如何进行资源估算，也就是资源估算的方法。还要去学习前辈们的经验，就是资源估算的一些经验法则等等的。接下来咱们再去了解一下资源估算的常见参考数据。资源估算的结果会影响到咱们的架构设计还有技术选型，所以说呢还是非常重要的。

2 架构评估基础系统性能衡量的基本指标

第一的一个我们在做系统架构设计的时候，我们要去做系统的资源预估，以此来判断咱们的这个架构设计是否合理，还有部署的时候大概需要多少资源。为了完成这些事情呢，我们就必须要对系统的性能啊有一个基本的认识。那衡量系统性能的这些基本指标，我们就必须要有所了解，否则呢这些任务也就很难完成。那另外一个呢就是咱们做的系统架构啊，最后是要落地的，我们是要去做架构验证的。也就是说到最后我们是要实际去测验咱们的这个架构是否能够支撑咱们所说的这些目标。那我们也需要知道衡量咱们系统性能的一些基本指标。

2.1 系统性能的指标

当然啊咱们这里去学这些东西呢，不会像学测试一样学的那么的详细。那我们快速的去看一遍，对此有一个基本的了解就可以了。那我们先来看一下，衡量系统性能的指标呢，其实有很多。那我们最常关注的呢大概有这么一些。第一个就是并发用户数，尤其是互联网的应用，很多问题都是高并发带来的。所以说并发用户数比这个东西要估算出来响应时间，就是rt(RT：Response Time，响应时间，就是发出请求到返回结果的时间。)还有qps/tps等等的。那除了这个呢，还有资源的性能指标。
我们经常关注的呢有这样一些像cpu内存、磁盘吞吐量、网络吞吐量等等的。

2.2 数据库指标

第一个肯定就是sql执行所耗的时间。另外呢就是qps、tps还有缓存命中率。注意啊，这里提的缓存是数据库的缓存，不是指的我们在做架构设计的时候，在数据库之外再去做的缓存层。还有呢就是连接数等等，

2.3 并发用户数

并发用户数呢它指的啊是实际同时在操作你这个软件系统的用户数量。那这里呢要跟注册用户数、在线用户数区分开。
那在某些网站的宣传当中，注册用户数都是数以亿计。但是这些只是注册了，这些人是否每天都在登录你的系统呢？
都在操作你的系统呢？
不一定。在线用户数呢指的是可能今天我登录了，但是我没有操作你的系统，我登录了过后就挂机了，然后我可能干别的去了，
这是在线用户数。而并发用户数呢，是指在一段时间之内啊，咱们真的在实际操作咱们这个软件系统的这样子的一些用户数量。
所以大家一听就知道，注册用户数远远大于在线用户数，在线用户数肯定要远远大于并发用户数。
但是为什么我们要关注并发用户数呢？因为对我们系统带来压力的，实际上是这些在操作系统的用户带来的。你挂机在那不用，对我的系统其实基本上没有什么压力，是这个道理吧？接下来看一下并发用户数的评估，这个对我们来讲非常的重要。
就是说拿到一个系统，你怎么来评估它的并发用户数量。如果说没有详实的历史数据做参考的话，业内通行的估计方法呢就是在一定时间段之内，在线人数的百分之十左右，也有放宽到百分之八到百分之十五的那这里头呢主要就是你要选取一定的时间段。

一般来说呢你可以选两个小时，但这个呢你可以选它能相对较多的时候。
比方说有些系统它是早上九点到十一点相对使用的人比较多，那么我就选这一段时间。那么它在这一段时间之内，假设说有一百万人在使用，那么我们就可以预估它并发用户数大概就在十万左右。因为你这一段时间在线操作的人才一百万，那么并发用户呢大概就在十万左右。但也有放宽到百分之八到百分之十五，你就按照这个比例去除就可以了。这个方法呢大家是要知道的。
接下来看一下响应时间。响应时间呢是从用户的角度来说，响应时间就是从用户发出指令到系统处理完成，然后返回结果给到用户这整个过程的一个时间长度。那咱们的直观感受就是我在页面上点击一个按钮，返回结果给到界面。
我看到那好，这个时间长度就是咱们所说的响应时间。咱们可以用一个公式来看一看这个响应时间。大体上呢，响应时间就等于网络传输时间。因为你发请求要网络传输到服务器，会有一个网络传输时间，然后加上服务器端的处理时间，然后再加上网络传输时间。因为它有响应回来，然后再加上页面解析的时间。那么这整个综合起来，大体上就是我们的响应时间。
那在这几个时间里面，向网络传输时间，不管是请求还是应答回来，我们都是难以控制的。而且呢我们也是很难去提高这个传输时间的。因为在公网的环境吧，咱们基本上啊都是不可控的。

2.4 网络延迟

所以说对于网络传输时间，基本上像咱们这种公网的系统的话，咱们很难去控制它。那么比较好控制的呢，就是服务器端的这个处理时间。我们可以通过优化，通过各种方式来使服务器这一端的处理时间呢尽量降低。当然啊网络传输时间也不是完全没有办法，一些基本的优化思路呢，比如说能够通过网络传就不传，就像页面有缓存的话，它就不走网络了，那这个很快呀。
能够走cdn的尽量走cdn，这就是所谓的数据尽量靠近用户。那么它网络传输的距离最短，这也能够得到优化呀。比如说能够压缩的尽量压缩传输，这也能得到一定的优化呀等等的。但是不管怎么样啊，像网络传输是要耗时间的，尤其是网络等待的这个时间，你是很难规避的这一点啊大家要理解，就大家在算这个响应时间的时候，不要光想成你服务器端的时间，还有其他的时间。

2.4 系统吞吐量

系统吞吐量呢是指单位时间之内系统能够处理的用户的请求数。其实就是单位时间通常是每秒能够处理用户多少请求，就称之为系统吞吐量。一般来说衡量指标呢就是qps、tps这样子的。
从业务角度看，吞吐量呢也可以用请求数每秒、页面数每秒或者人数每天等单位来衡量。如果从网络角度看呢，吞吐量可以用每秒多少字节来衡量。那这些呢大家了解一下，再看一下常见的指标。
第一个呢是hps，就是每秒点击次数，单位当时每秒多少次了。
第二个呢是qps，是指服务每秒能够响应的查询次数。
第三的一个tps是指每秒服务能够处理的事物的数量。

一般情况下呢，qps要比tps要大，为什么呢？
因为一般用t p s来衡量整个业务流程，就说我们去判断这是个t p s的时候，一般呢是执行一个业务功能，它完成的是一个业务功能的处理。
而qps呢是衡量的接口的查询次数。
那注意这两个是有一些差别的，尤其是从前端页面上。
你比方说你点开一个页面，这叫一个t p s，它只算一次，但是这个页面可能会发起五次甚至十次后台的查询请求，那个就是q p s。比如说它下载h t m l要发一次请求，里面有两个异步要发请求，图片要发请求，g s链接要发请求等等的。
所以说一般情况下呢，q p s会比t p s大。但是如果我们只是去测试后台的这个接口的话，它俩很可能是差不多的。
这一点呢大家注意一下。

2.5 资源性能指标

第一个当然就c p u了。一般来说呢，我们去观察c p u指标的时候，c p u的利用率应该低于百分之七十。如果高于百分之七十，那我们就要开始注意这个系统可能有问题。一般高于百分之八十或者百分之八十五，那这个系统就要开始进入危险期了。那在这里头呢，大家去观察指标的时候，要注意多核的问题。因为它有时候显示啊，它是按照每盒百分之百来计算的。
比如说你的机器有四核，你很可能会看到你的那个c p u的使用率飙到了百分之三百多，这都是可能的。所以说呢你要注意它这个指标是不是按照每盒百分之百来计算的。

那第二的一个观察的指标就是内存了。内存这一块呢大家注意并不是说内存利用率达到百分之百，系统的内存就有瓶颈。
因为呢现在的操作系统啊为了最大化的去利用内存，它会在内存当中存放很多的缓存。
因此呢我们要去注意swap就是s w a p与虚拟内存交换空间的这个利用率。一般情况下呢swap的交换空间利用率要低于百分之七十，如果正数太高，那么将会引起系统性能低下。所以说呢大家不要看到内存百分之百就很惊慌，不一定有问题。

第三的一个呢是磁盘吞吐量。磁盘的指标啊主要有每秒读写多少兆、磁盘繁忙率、磁盘队列数、平均服务时间、平均等待时间、空间利用率等等的一系列的指标。其中呢磁盘繁忙率是能够直接反映磁盘是否有瓶颈的重要依据。
一般情况下我们要求它呢低于百分之七十。大家注意哦，你看这很多资源的性能指标都是百分之七十为限。
再看网络吞吐量。网络吞吐量的指标主要有每秒有多少兆流量进出，一般情况下不能超过设备或者是网络链路最大传输能力的百分之七十。你看又是一个百分之七十。所以说呢对于资源的性能指标啊，大家在观察的时候要注意呢，他的这些主要指标都不要超过百分之七十。

这意味着未来我们进行系统资源预估的时候，我们也应该按照百分之七十为界限去预估，而不能照百分之百。比方说我一个tomcat假定想给它分四g的内存，然后我这台服务器呢是32g内存。那是不是我就能够分八个tomcat呢？
这是不可以的。首先第一内存的这个使用率尽量不要超过百分之七十。那好，这就只能有21-22g然后我还得留一点操作系统自己用吧。所以说大体上你分五个tomcat。这是比较合适的，4*5g嘛，再留个一两g两三g给操作系统自己用，其他的就应该空着，而不能够按照32g来除以四得八这样子来计算。所以说你在估算资源的时候，也会存在这个百分之七十的指标的问题。
再来看一下数据库性能指标。当然第一个sql耗时，这个咱就不多啰嗦了。sql执行肯定要耗时嘛，你要去关注咱们有什么mysql的记录啊，这个就不多说了。另外呢qps数据库里面的啊每秒查询次数，就是你select这个次数，tps每秒四五次数。
然后就是缓存的命中率。

一般来说啊，这里所说的缓存是指数据库的缓存。
常见的呢有这么几个，大家看一下。
第一个呢就是buffer，它是索引缓冲区的命中率，这个对于提高查询性能是很有好处的。
第二个呢是quite cache，就说查询缓存命中率。
第三的一个呢是table cache，就表缓存的命中率。
第四的一个呢是create cache，就是存缓存命中率。
一般来说这这些命中率应该都在百分之九十以上才是比较好的。
如果过的话就要考虑一下，这可能会有问题。
另外一个数据库性能指标就是去查看所主要看两个，一个是所等待的次数，另外是所等待的时间。
当然啊所等待的次数肯定是越低越好，等待的时间肯定是越短越好好差不多系统性能衡量的这个基本指标呢，我们就先看到这儿。

3 架构评估基础服务端性能测试

其实啊咱们并不是要去学测试，主要是咱们进行架构设计的时候要做资源评估。还有呢架构设计做完过后，咱们需要对这个架构设计进行验证。那么我们需要去做一些性能方面的测试。因此呢咱们在这里了解一下服务端性能测试大概都有哪些。
这里呢咱们会很简略的过一遍，作为大家的一个了解内容。那我们先来看第一个，根据不同的这个测试目的啊，性能测试呢又可以分为很多种类型，比较常见的就下面这几类。
第一种叫基准测试，第二个叫负载测试，第三个叫压力测试，第四个叫疲劳强度测试，第五个叫稳定性测试，第六个叫容量测试。这都是非常常见的几种。

3.1基准测试

它呢是指的模拟单个用户来执行业务场景，然后去获取系统的性能指标。就一个用户来操作这些功能，那么大概每秒通过的这个q ps、tps, 这是多少能够得到一定的性能指标。
那么这个有什么作用呢？通常就是将基准测试时采集的这个系统性能指标啊作为基准测试的结果，为后续并发压力测试的性能分析提供参考依据。

3.2 负载测试

负载测试呢指的是模拟系统在正常负载压力的场景下来考察系统的性能指标。那什么叫做正常负载压力呢？
一般来说指的是用户对这个系统能够承受的最大业务负载量的一个要求。也就是说我们应该按照用户最高期望值来进行压测，这就是呢负载测试。通常呢负载测试是最典型的性能测试类型，能够通过实时负载测试啊得到性能拐点。
也就是说这个系统在一定时间之内肯定是在持续上升的这个性能。
那么上升到一定程度，你再增加并发人数，再增加压力的时候，它的性能指标不但不会往上升了，反而会逐渐开始往下降。
那么这个地方就叫做性能拐点，也叫做最佳性能点，这就是负载测试。

3.3 压力测试

压力测试呢会对被测的系统啊采用逐步加压的策略。在加压的过程当中呢去考察系统性能指标的一个走势情况，最终找出系统在出现性能拐点时候的并发用户数，也就是呢系统能够支持的最大并发用户数。
也就是说压力测试实际上是为了发现在多大的这个并发压力下，系统的这个性能呢会变得不可接受，或者说出现性能拐点。
一般来说出现性能拐点的时候，系统就有崩溃的风险。

3.4 疲劳强度测试

疲劳强度测试呢是对系统模拟出系统能够承受的最大业务负载量，然后观察一段时间，也就是说在满负载的情况下，让这个系统呢跑一段时间。疲劳强度测试呢它更关注系统在长时间运行情况下，系统性能指标的一个变化情况。
比如说这个呢跟前面讲的负载测试有类似之处，但是也有一些不同。前面的负载测试呢是为了验证这个系统能否满足用户预期的业务压力的场景。而咱们这个疲劳强度测试呢，主要是关注长时间运行情况下，系统性能指标是如何变化的。
再看稳定性测试。
稳定性测试呢是把用户真实会发生的这个场景啊放大三到五倍，然后呢在线上运行一段时间，以此来测试系统是否会出现问题。
当然这个啊要根据实际情况，有可能呢你不能够在真实的线上环境去做稳定性测试，也可以在你的测试环境或者开发环境里面做这样子的测试。

3.5 容量测试

容量测试呢是为了测量系统的最大容量，从而为系统的扩容性能优化提供参考，节省了成本的投入，提高资源利用率。
至于具体他怎么去做呢，咱们这里就先不去讲了。我们后面呢做资源规划的时候啊，也会讲到很多容量的规划。
那对于这些测试类型呢，咱们主要是了解一下，知道有这么一些东西。再来看一下性能测试开展的一个基本流程，咱们也了解一下。一般来说呢首先是获取性能测试的需求，然后去确定性能的目标。第三个一个呢就开始构建性能测试的环境。第四个一个是编写性能测试的脚本。第五的一个呢就是构建性能测试的场景。第六的一个就开始执行性能测试，然后分析这些结果，最后呢就是测试结果的分析和报告了。这些测试的流程啊大家应该都不陌生，就算咱们没有实际去做，起码也见到过测试部门的人员去做过。最后呢，咱们简单了解一下性能测试的一些工具。
当然这里呢咱们简单的说几个。

第一个呢，当然就是大名鼎鼎的note runner收费的这个东西很好，开源的就是jemter，这也是一个非常不错的性能测试工具。
另外一个呢就是简单型的阿帕奇自带的a b好，有关于性能测试方面的内容呢，咱们就简单的了解这么多就可以了。