我们先要有一个基本概念：PV 、 UV 、 QPS、RTPV：Page View 页面访问量，用户每一次对网站中的每个页面访问均被记录 1 次。用户对同一页面的多次刷新，访问量累计。UV：Unique Visitor 独立访客，1天内访问某站点的用户数。QPS：Query Per Second  每秒请求数（服务器在一秒的时间内处理了多少个请求） 简明公式：QPS = req/sec = 请求数/秒。RT：Response Time，一个请求的响应时间。需要的机器数量 = 峰值时间每秒QPS / 单台机器的QPS

基本概念

我们先要有一个基本概念：PV 、 UV 、 QPS、RT

• PV：Page View 页面访问量，用户每一次对网站中的每个页面访问均被记录 1 次。用户对同一页面的多次刷新，访问量累计。
• UV：Unique Visitor 独立访客，1天内访问某站点的用户数。
• QPS：Query Per Second  每秒请求数（服务器在一秒的时间内处理了多少个请求） 简明公式：QPS = req/sec = 请求数/秒。
• RT：Response Time，一个请求的响应时间。

需要的机器数量 = 峰值时间每秒QPS / 单台机器的QPS

估算

我们就用C端服务来作为例子，C端的链路一般都很长，因为经常需要各种RPC，所以我们的服务只是链路中的一环。为了用户体验，我们就先假设，整条链路RT是1S，超过就熔断，而链路的每环一般都不会超过10个环节。所以一般来说某一个环节最长只能到100ms

我们去掉请求和响应的网络io，粗略70ms，也就是说在70ms内必须要处理完自己的业务逻辑。自己的业务逻辑包括但不限于

1. 请求redis各种数据
2. rpc其他服务的数据
3. 做业务逻辑运算

当然这些是可以并发处理的，不会串行处理。 现在我们知道了70ms内必须要处理完这一个请求。

假设我们每台实例统一规格为x核xG。问题来了？x核xG的机器在1s内可以处理多少请求数呢？不知道，核的不同会导致结果的不同，我们一般会把服务部署到这台机器上做压测。

假设 x核xG 压测的结果如下：

1. QPS 为 1000 的情况下，CPU的使用率为35%，内存使用率为25%
2. QPS 为 1500 的情况下，CPU的使用率为50%，内存使用率为40%

同时，我们需要观察RT时间，如果RT不符合我们所规定的70ms，就需要优化、或者扩容，升配处理了。

这里我们强调一点，我们的应用一般分成io密集型和计算密集型。io密集型就是会有很多取数的io请求，比如redis拿数会有很多，一般是一些多数据源但计算简单，而计算密集型就像一些算法模型，除了gpu，还需要大量的高规格cpu。所以可以根据自身的业务特点去调整cpu的规格。

我们的cpu使用率不能超过50%，大概会控制在30～40%。互联网的应用都有高低峰的使用时间，比如刷短视频的时间的低峰时间端一般就是晚上的0点～8点左右，其他时间就是高峰期。

假设我们整个服务QPS在高峰时期约30k，需要的机器数量 = 峰值时间每秒QPS / 单台机器的QPS = 30k/1k = 30 台。这样我们就可以先简单的拍定需要30台机器实例。如果上线的时候发现不够，再做扩容或者缩容。

问题又来了，这些机器实例部署在哪里的机房呢？

机房位置选择

在我们实际部署中，最慢的一般都不是cpu的计算，而是各种io、磁盘io、网络io等等。。

举个例子：如果我们的服务部署在北京机房，但是redis、mysql等db资源部署在广州机房，那么就会导致io时间过长。

所以我们一般会将服务和服务所需要用的各种资源部署在同一个地方，减少跨机房导致的网络io过长的问题，并且为了让分散在全国各地的用户都能快速访问到，就需要各个中心城市都部署。

比如北方的北京，南方的广州，西边的兰州，东边的上海，中间的武汉，这样就能保证用户到服务机房的io尽可能的短。

所以我们会针对全国每个地区的QPS做统计，并且根据QPS占比分配机器。如果这五个地方刚好平均了QPS，那么就是每个地方部署六台机器。一般来说的QPS都不会太平均，通常热门城市的QPS会大很多，比如北京、上海、广州就可以多部署一些机器。

确定好机器的实例个数之后，再用分级发布来发布应用，并不断观察机器状态，如果QPS和预先估计设想的QPS有较大误差，就做紧急扩容，再做观察！

参考

[1] https://www.cnblogs.com/zhaojinhui/p/16802391.html

[2] https://blog.csdn.net/YouMing_Li/article/details/136564018