网站高可用方案选择

起因

由于项目进度比较紧，业务需求多，变更频繁等原因，我们网站后台一直没有实现一个高可用的方案，只有一个单点的入口，架构方案是后台有三台机器，在一台机器上装了一个nginx负责对外，并反向代理给其它三台机器的后台进程，前端对后台的请求指向这台nginx，这样如果这台装nginx的机器挂掉，那我们整个后台也就挂掉了。其实也发生过这样的事，有一次新来的校招小伙一不小心改了这台机器的防火墙，导致我们全站挂了10分钟…

设计

为了避免这样的事情再发生，我们把后台高可用提上了日程，方案其实也是比较多的：

第一个方案，接入公司的TGW网关，TGW是公司在HAPROXY基础上做的一个公司级网关，负责反向代理，负载均衡，高可用等功能，但是由于TGW只支持外网IP，请求路由是外网走到前台Nginx，前台Nginx再走到外网IP这样就不合理了，所以后台接入TGW来做高可用基本放弃

第二个方案，接入L5，L5是公司专门用来做内网负载均衡的工具，原理是在机器上部署一个L5 agent，需要转发给后台的请求首先请求L5 agent拉取负载均衡策略配置，获取一个IP+端口号后再向后台转发，L5 agent负责维护同步远程的负载均衡配置，这个方案其实是公司在后台负载均衡的一个通用方案，但是这个工作主要是前台要接入L5，前台人力有限，没时间搞这个，遂也放弃了…

第三个方案，使用keepalived + vip的方式，这个方案只能做灾备，无法做负载均衡，并且需要申请一个内网的虚拟IP，我们可以在后台每台机器上配置对等的nginx来做负载均衡，扩容的话需要修改后台每台机器的nginx，这个方案咋一看是可以解决我们的问题的，于是初期就采用了这个高可用方案，但是随后就发生了一个事件，我们网站由于做活动产生了爆发式的流量，很多后台请求放回502，经过分析，是后台入口的nginx机器socket耗尽，大量time_wait导致的，可见这个方案还是有单点瓶颈，后台入口nginx只有一个。

第四个方案，前端nginx做负载均衡指向后台每台机器对等的nginx，这样解除了后台nginx单点瓶颈的问题，也能做灾备和负载均衡，缺点也很明显，后台扩容时要同时修改前端和后台的nginx配置。

总结

上面的第四种方案使我们现网运行目前采用的方案，但是很明显第二种方案是最好成本最低的方案，做项目就是这样，由于各种原因，现网正真跑的并不是你知道的最好的方案，都是各种补丁堆起来的…