前言

随着PC、移动互联网的快速发展，越来越多的人通过手机、电脑、平板等设备访问各种各样APP、网站系统。国民级的产品应用接入层QPS甚至能够达到百万、千万级别，那么针对这么大请求量，系统接入层该如何设计才能确保能够承载大请求的同时，保证可用性、拓展性呢？通过该文章我们来梳理一下接入层架构方案

1、单机架构

一个系统投放到线上初期，并不会有大量的用户进行访问使用，不存在大量请求造成服务器负载过高，故障宕机的情况发生，一个系统的QPS（每秒查询数量）可能连5都不到。针对这种QPS很小的情况，我们只需要一台Tomcat服务器对外提供服务就可以满足要求了。

用户通过浏览器输入域名，域名会被DNS域名解析服务进行解析，就能够得到目标服务器的IP地址，有了IP地址就能够将HTTP请求包发送到目标节点上。所有的客户端HTTP请求都会发送到这1台服务器上，服务器对目标HTTP请求进行响应操作，架构图如下：

这在系统初期还是可以满足要求的，但是随着用户量的越来越多，就会导致单台Tomcat要处理更多的请求，随着用户数的增长，并发压力主要落在单机的Tomcat上，响应逐渐变慢。假设 SpringBoot 内嵌的Tomcat 能够承载的QPS是1000，此时接入层请求量达到 3000 QPS，此时单台Tomcat根本无法满足大请求量场景（需要3台）。就可以通过DNS轮询方案解决该问题。

2、DNS 轮询

上面提到，一个域名网址通过DNS服务可以就解析出IP地址，一台Tomcat通过IP地址对外提供服务。只要一个域名能够轮询解析出3个IP，就能够通过该域名轮询访问3台Tomcat服务，上面提到的单机Tomcat无法处理大流量请求的问题就迎刃而解了。通过一个域名解析出n个IP的操作就是DNS轮询，架构图如下：

这样通过DNS轮询解析多个IP确实解决了更大请求量的问题，但是随着请求量的不断上升，还是需要不断的横向扩展Tomcat资源，申请更多的IP地址，一个域名要解析出更多的IP地址（无疑是对IP资源的浪费），而且有个致命的问题就是：无法进行故障检测。也就是说如果出现了某台Tomcat宕机，DNS还是会将请求发送给宕机的Tomcat，虽然满足了高性能，但是并不满足高可用的特性，此时不得不提到Nginx。

3、Nginx 单机

上面提到了，DNS轮询方案不能够保证高可用（不能检查到哪个Tomcat发生故障），而且随着用户的增多造成IP地址的浪费（需要更多的Tomcat提供服务），通过Nginx就能很好的解决上述提到的问题，Nginx作为一款高性能反向代理负载均衡服务器，理想情况下能够抗住3~5W QPS，我们只需要一台Nginx服务器对n台Tomcat集群进行反向代理、负载均衡、故障转移，就能够解决上述提到的问题。

所有的用户请求都不会直接发送到Tomcat服务器，而是通过Nginx服务器进行路由转发到目标Tomcat上，只需要域名解析一个IP地址对应到Nginx上，不需要为每台Tomcat都申请公网IP地址，Nginx与Tomcat集群之间通过内网IP进行通讯即可，架构图如下：

此时就算某台Tomcat发生故障不可以处理请求，Nginx会检测Tomcat运行状态并进行故障转移，不会继续将HTTP请求转发宕机的Tomcat节点上，而且Nginx能够承受极高的并发量，我们可以随意横向拓展Tomcat服务器以满足更高请求量的要求，省掉了大量的公网IP地址，上图中只是画了3台，实际上能够代理更多的Tomcat资源。但是有一个问题，就是Nginx如果出现了故障，那就会导致整个系统的请求入口不可用，即便Tomcat集群规模在大，能处理的请求量再多，也无济于事，能否有一个办法保证Nginx的高可用呢？当然有，那就是通过Keepalived来处理单点问题。

4、Nginx 主备 + Keepalived

为了防止单点Nginx宕机导致接入层请求入口不可用，这里可以通过Keepalived来保证Nginx的高可用，这里就需要2台Nginx（一个为主，另一个为备），这里的主备并不是主从那样的关系，也就是说只有主节点Nginx才提供服务，备节点Nginx并不会处理用户请求，只要当主节点出现宕机，才会使用备用节点代替主节点提供服务，这样就避免了Nginx出现单点故障的问题了！但是缺点就是造成了资源的浪费（毕竟主节点正常运行时，备用Nginx不工作！）

值得一提的是，阿里云ECS是不支持Keepalived这套方案的，所以不要妄想在阿里云ECS上使用这套高可用架构。

每台Nginx服务器上都需要安装Keepalived，使用keepalived软件模拟出虚拟IP，然后把虚拟IP绑定到多台Nginx服务器上，不过需要有独立的公网IP用于映射虚拟IP，浏览器访问虚拟IP时，会请求到主Nginx服务器，通过虚拟IP作为接入层请求的入口，主节点Nginx宕机时就会出现IP漂移，将访问入口转接到备Nginx节点，架构图如下：

完美！解决了Nginx单点故障的问题，看起来确实没什么问题了，不过别忘记了，我们的标题是百万级QPS，上面这个架构也不过能抗个上万级别的QPS，别说百万级别，连几十万级别都很难了，这里有人可能会提到是不是可以加DNS轮询，当然可以！不过就算有多套主备Nginx组合，还是很难达接受百万级别QPS的场景。对于Nginx这种七层负载负载均衡器来说，想要扛百万的QPS还是不太现实的。这是我们可能会想，能否找个性能更强大的负载均衡器给Nginx做反向代理呢（好像俄罗斯套娃），当然有，这里就得提一下四层负载均衡器 LVS了。

5、LVS 主备 + Keepalived + Nginx 集群

LVS一般被用作于负载调度器，它与Nginx的功能类似，但不同点在于：LVS工作在OSI七层网络模型中的第四层-传输层，而Nginx则是工作在第七层-应用层，同时LVS并非是以进程的方式运行在操作系统上的，而是直接位于Linux内核中工作，因此LVS的性能一般是Nginx的十倍以上。

通过四层负载均衡器为七层负载均衡器做请求接受、分发是常用的方案，因为四层负载均衡器性能更强大。如果一台Nginx能够处理3W QPS，那么一台LVS负载均衡器就能够处理30W左右QPS，差距是不是很大！所以我们可以使用LVS接入层请求入口，收到大量请求后再转发给Nginx服务器，然后再通过Nginx服务器路由到Tomcat服务上处理请求，LVS再通过Keepalived提供的IP漂移机制实现单点高可用，这套架构就能够抗住几十万级别的QPS量级了！如下图：

说到这里，我觉得大家应该也明白了，在这个架构的基础上，在使用DNS轮询方案就能够构建出百万级别的QPS接入层。

6、LVS 主备 + Keepalived + Nginx 集群 + DNS 轮询

毕竟单台LVS负载均衡就能扛几十万，加入单台能够扛35W+ QPS，那么只需要DNS轮询解析3个公网IP地址，就能够处理百万级别请求量级，架构图如下（图中我只画了两个LVS主备）：

通过上述这套架构，能够为接入层提供百万级别的QPS并发，在这里补充一句，上面提到LVS是四层负载均衡器，确实比Nginx这种七层负载均衡器要性能强大太多太多了，但是还有硬件版本的四层负载均衡器，例如：F5，单台就能够达到百万级QPS，但是缺点就是价格太贵太贵了，所以四层负载均衡器如果预算不足，可以使用LVS这种软件负载均衡，性能也是很强的，如果预算充足追求性能，可以使用F5这种氪金操作，当然还有一种方案就是购买云服务厂商的负载均衡服务，例如：阿里云SLB，LVS + Keepalived 也是阿里云SLB负载均衡服务在使用的方案。

最后提一嘴，通过上述这套演进可以发现，别说百万级别，就算是千万级别，也不过是进行拓展加资源就能够解决（LVS替换F5、DNS轮询更多IP地址、升级服务器配置等…），但是话又说回来，你所在公司的业务是否真的需要这么强大高性能的接入层架构，本篇文章提到的所有方案没有好坏之分，只有合适不合适，过度设计是可耻的，选择符合你业务场景的架构方案才是明智之举。