keepalived+nginx打造高可用web应用的架构方案

看了一篇web应用的架构文章，作为web项目首先保证高可用，如果是互联网面向用户的项目呢，高可用其中一点就是要面对高并发。下面对高可用方案进行总结，本文只讨论到web service层，数据层暂不讨论。

 

单点往往是系统高可用最大的风险和敌人，应该尽量在系统设计的过程中避免单点。方法论上，高可用保证的原则是“集群化”，或者叫“冗余”：只有一个单点，挂了服务会受影响；如果有冗余备份，挂了还有其他backup能够顶上。

 

保证系统高可用，架构设计的核心准则是：冗余。

 

单机web最初架构是DNS+web server。 一台公网ip可以对外提供服务。如果这台机器故障则web服务不可用。解决方案就是增加一台备用web server，这样单机故障之后可以启用第二台机器顶上，实现高可用目的。

 

如果把这个思路做到平滑无感知切换机器，那么一套可行的方案就是DNS+(keepalived & nginx反向代理)+web server三层架构，这个架构基本上可以解决90%以上的web项目需求。结构图如下：

 

nginx使用proxy、upstream模块做为反向代理+负载均衡服务器，upstream模块自带多个负载均衡算法、自带健康检查，可以把故障web service屏蔽掉，这样保障了nginx到web service高可用。

 

那么万一，nginx故障了呢？ 所以配上keepalived。 在两台nginx server上配置keepalived，设置公网ip为虚拟ip，master 机器工作，当master机器nginx故障，keepalived自动启用backup机器，用户无感知。

 

这个架构的优点是可以在nginx到web server机器通过加机器来解决高并发问题。nginx单机并发能力非常强，上万qps。缺点是有一台nginx机器基本上一直处于备用状态，机器利用率50%，为了高可用可以接受。

 

如果，并发量更大一点呢，qps超过5万呢？  能达到这个并发量，那公司的业务量很可以了，创始人应该可以财务自由了。 既然达到nginx的并发极限，当时是要增加nginx数量了。所以上面架构升级为四层，即DNS+（keepalived-lvs）+nginx+web service 来实现，这个架构可以解决99.9%的高可用、高并发web项目。 架构图如下：

 

 

从图中可以看出，keepalived机器上不再部署nginx server，两台keepalived 机器，在keepalived.conf中开启负载均衡配置，一个虚拟ip对应N个nginx server，设置负载均衡算法，设置nginx server健康检查，保证N台nginx server是可用的，自动屏蔽故障nginx server。 在多台nginx server中设置虚拟ip，把vip添加到 tunl0 网卡上。 nginx server到web server的配置和上一个架构一样。

 

这样，通过横向扩展nginx server 和 web server机器的方法抗5个明星同时出轨的流量是没有问题的，99.9%的web项目都可以稳定运行了。 如果，有人问，我的并发量还要大呢？首先恭喜你的公司市值至少100亿美金了，其次，解决方案是再买几个公网ip，设置成多个vip，通过DNS轮询方式把流量分发到多个keepalived机器上，即DNS轮询+（keepalived-lvs）+nginx+web service 来实现。

 

具体配置信息参考下面几篇文章：

 lvs+keepalived群集配置

 

 LVS 和 Keepalived 的原理介绍和配置实践

 

 lvs详细介绍及lvs和keepalived的使用

 

究竟啥才是互联网架构“高可用”