CTO眼中系统容量的评估

1.用户访问网站的过程

DNS解析->防火墙->WAF->代理服务器->应用服务器

用户在浏览器上输入网址域名或者打开APP

DNS解析域名获取到服务器的IP

发起TCP连接请求，建立TCP连接

发送HTTP请求

代理服务器（Nginx）转发HTTP请求

WEB服务器接收HTTP请求，处理后返回响应

客户端收到响应数据，渲染页面，展示给用户

https请求过程稍微有点不同，它会请求服务器的443端口，服务器端要安装SSL证书，在客户端和服务器之间建立起一条SSL安全加密通道，使得请求在传输过程中将不会被查看、窃取和修改。

为了提高网站/APP响应速度和成功率，大部分都采用了CDN，CDN解决了地区分布、带宽、服务器性能带来的访问延迟问题，适用于静态文件加速、点播、直播等场景，用户可就近取得所需内容。

CDN使用了DNS的CNAME技术，在用户访问某网页、视频等资源时，会将域名指向另一个CDN中定义的域名，再解析成另一个IP地址来供客户端进行访问，使客户端访问时进行加速。

2.为了评估系统的整体性能，先看一下常用指标的基本定义

并发数：系统同时处理的请求数。

响应时间（RT）：Response Time：客户端发一个请求开始计时，到客户端接收到从服务器端返回的响应结果结束所经历的时间，响应时间由请求发送时间、网络传输时间和服务器处理时间三部分组成。

TPS：Transactions Per Second，指服务器每秒处理的事务次数，例如下单、支付的性能。

QPS：Queries Per Second，指服务器每秒处理的查询次数，例如浏览商品，查询订单的性能。

QPS（TPS） = 并发数 / 平均响应时间，假设1秒钟200个请求，处理每个请求平均需要2秒，那么QPS = 200 / 2 = 100

PV（Page View）：页面访问量，即页面浏览量或点击量，用户每次刷新即被计算一次

UV（Unique Visitor）：独立访客，统计1天内访问某站点的用户数(以cookie为依据)

峰值QPS：每天80%的访问集中在20%的时间里，这20%时间叫做峰值时间，公式：( 总PV数 * 80% ) / ( 每天秒数 * 20% ) = 峰值时间每秒请求数（QPS）

3.电商大促情况下，系统是否可以撑得住，我们如何来评估？

流量来源：小程序、H5、APP

大促流量预估：根据历史经验值，以及推广力度，预估出大促期间的PV，UV

当前各链路容量统计：网络接入层—DNS/防火墙/WAF/F5，应用接入层—Nginx，Web应用层—tomcat，服务层—dubbo，消息层—mq，数据层—db/redis，主要考察服务器配置（CPU+内存），单机容量

核心链路梳理：交易，风控，基础服务等核心系统

核心链路监控：服务器监控zabbix、业务监控平台ump，参考技术（六），设置好监控阈值

压测：线上/线下、读写/仿真/引流/集群隔离/缩容压测、单机/集群/全链路（最关键的就是压测）

预案，参考我的另外一篇CTO眼中的系统高可用

举例：

如果促销10分钟内，预估100万PV，那么它的峰值QPS = 1000000 / （10 * 60）≈ 1667，如果A服务单机容量在50%水位时(以单机的50%资源使用率作为扩容依据)，QPS = 500，为保障服务高可用，预留30%机器资源做扩容buffer，那么A服务线上需要部署的机器数为：(1 + 30%) * (1667/500）= 4.3 ，取整5，所以最终A服务线上需要部署5台服务器。

以上只是一个基本的预估算法，实际上要复杂的多，因为涉及到整个链路以及互相依赖的服务，最关键的一点是梳理清楚所有的依赖关系，哪些可以降级，哪些是强依赖，相对于的服务器也需要扩容，所以平时做好压测，是保证服务高可用的收效手段，同时应急预案也要完善。

当年设计的一个支持100万用户同时在线、20万并发的直播答题系统的容量预估，上线后，最高80万以上用户同时在线，系统平稳运营，没出现故障。

容量评估准确与否，直接影响到大促的效果，以及用户对平台的信任，所以作为技术决策者，务必要了解基本的方法论。