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.电商大促状况下，系统是否能够撑得住，咱们如何来评估？

• 流量来源：小程序、H五、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万以上用户同时在线，系统平稳运营，没出现故障。

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