域名到站点的负载均衡技术一览(主要是探讨一台Nginx抵御大并发的解决方案)(转)

继上一篇文章Http://www.cnblogs.com/EasonJim/p/7807794.html中说到的,Nginx虽然很强大,但是面对大并发时,一台Nginx总是有限的。即使后端有多台Nginx组成的集群时,前端毕竟只有一台Nginx,资源往往有限。

下面将介绍应对这样的情况应该有的解决方案,其实原理就是集群,使用的是LVS。

我猜测和简单的理解(观点虽然是错的,但是好理解,如果要深入原理远没有这么简单):为什么LVS的集群能够抵御这么大的并发,一切都出在VIP上,首先依托LVS的负载均衡调度器,这个是在Linux内核级别的,估计是在网络七层中的第一层就转发了,然后就是链表处理,然后把请求转发到各个集群,再到Nginx。既然是内核级别的,那么资源肯定占用的非常少,只做个最基本的转发。

下面是详细的介绍:

一、问题域

Nginx、LVS、Keepalived、F5、DNS轮询,往往讨论的是接入层的这样几个问题:

1)可用性:任何一台机器挂了,服务受不受影响

2)扩展性:能否通过增加机器,扩充系统的性能

3)反向代理+负载均衡:请求是否均匀分摊到后端的操作单元执行

二、上面那些名词都是什么概念

1)Nginx:一个高性能的Web-Server和实施反向代理的软件

2)LVS:Linux Virtual Server,使用集群技术,实现在Linux操作系统层面的一个高性能、高可用、负载均衡服务器

3)Keepalived:一款用来检测服务状态存活性的软件,常用来做高可用

4)F5:一个高性能、高可用、负载均衡的硬件设备

5)DNS轮询:通过在DNS-Server上对一个域名设置多个IP解析,来扩充Web-Server性能及实施负载均衡的技术 

三、接入层技术演进

【裸奔时代单机架构】

裸奔时代的架构图如上:

1)浏览器通过DNS-Server,域名解析到IP

2)浏览器通过IP访问Web-Server

缺点

1)非高可用,Web-Server挂了整个系统就挂了

2)扩展性差,当吞吐量达到Web-Server上限时,无法扩容

注:单机不涉及负载均衡的问题 

【DNS轮询】

假设Tomcat的吞吐量是1000次每秒,当系统总吞吐量达到3000时,如何扩容是首先要解决的问题,DNS轮询是一个很容易想到的方案:

此时的架构图如上:

1)多部署几份Web-Server,1个Tomcat抗1000,部署3个Tomcat就能抗3000

2)在DNS-Server层面,域名每次解析到不同的IP

优点

1)零成本:在DNS-Server上多配几个IP即可,功能也不收费

2)部署简单:多部署几个Web-Server即可,原系统架构不需要做任何改造

3)负载均衡:变成了多机,但负载基本是均衡的

缺点

1)非高可用:DNS-Server只负责域名解析IP,这个IP对应的服务是否可用,DNS-Server是不保证的,假设有一个Web-Server挂了,部分服务会受到影响

2)扩容非实时:DNS解析有一个生效周期

3)暴露了太多的外网IP

【Nginx】

Tomcat的性能较差,但Nginx作为反向代理的性能就强多了,假设线上跑到1w,就比Tomcat高了10倍,可以利用这个特性来做扩容:

此时的架构图如上:

1)站点层与浏览器层之间加入了一个反向代理层,利用高性能的Nginx来做反向代理

2)Nginx将Http请求分发给后端多个Web-Server

优点

1)DNS-Server不需要动

2)负载均衡:通过Nginx来保证

3)只暴露一个外网IP,Nginx->Tomcat之间使用内网访问

4)扩容实时:Nginx内部可控,随时增加Web-Server随时实时扩容

5)能够保证站点层的可用性:任何一台Tomcat挂了,Nginx可以将流量迁移到其他Tomcat

缺点

1)时延增加+架构更复杂了:中间多加了一个反向代理层

2)反向代理层成了单点,非高可用 

【高可用方案Keepalived】

为了解决高可用的问题,Keepalived出场了:

此时:

1)做两台Nginx组成一个集群,分别部署上Keepalived,设置成相同的虚IP,保证Nginx的高可用

2)当一台Nginx挂了,Keepalived能够探测到,并将流量自动迁移到另一台Nginx上,整个过程对调用方透明。


优点

1)解决了高可用的问题

缺点

1)资源利用率只有50%

2)Nginx仍然是接入单点,如果接入吞吐量超过的Nginx的性能上限怎么办,例如qps达到了50000呢?

【垂直扩容方案 LVS/F5】

Nginx毕竟是软件,性能比Tomcat好,但总有个上限,超出了上限,还是扛不住。

LVS就不一样了,它实施在操作系统层面;F5的性能又更好了,它实施在硬件层面;它们性能比Nginx好很多,例如每秒可以抗10w,这样可以利用他们来扩容,常见的架构图如下:

此时:

1)如果通过Nginx可以扩展多个Tomcat一样,可以通过LVS来扩展多个Nginx

2)通过Keepalived+VIP的方案可以保证可用性

多数的公司到这一步基本就能解决接入层高可用、扩展性、负载均衡的问题。

好吧,不管是使用LVS还是F5,这些都是scale up(垂直扩展)的方案,根本上,LVS/F5还是会有性能上限,假设每秒能处理10w的请求,一天也只能处理80亿的请求(10w秒吞吐量*8w秒),那万一系统的日PV超过80亿怎么办呢?

【水平扩容方案DNS轮询】

水平扩展,才是解决性能问题的根本方案,能够通过加机器扩充性能的方案才具备最好的扩展性。

facebook,google,baidu的PV是不是超过80亿呢,它们的域名只对应一个IP么,还是得通过DNS轮询来进行扩容

此时:

1)通过DNS轮询来线性扩展入口LVS层的性能

2)通过Keepalived来保证高可用

3)通过LVS来扩展多个Nginx

4)通过Nginx来做负载均衡,业务七层路由

四、总结

稍微做一个简要的总结:

1)接入层架构要考虑的问题域为:高可用、扩展性、反向代理+扩展均衡

2)Nginx、Keepalived、LVS、F5可以很好的解决高可用、扩展性、反向代理+扩展均衡的问题

3)水平扩展scale out是解决扩展性问题的根本方案,DNS轮询是不能完全被Nginx/LVS/F5所替代的

 

参考:

Https://www.cnblogs.com/wade-luffy/p/6406394.html(以上内容转自此篇文章)

posted @ 2017-11-12 22:54  EasonJim  阅读(2399)  评论(0编辑  收藏  举报