分布式项目中Nginx应用场景研究

众所周知nginx一般有两个作用，一个是负载均衡、一个反向代理。但是自从接触了duubo+zookeeper（或者springcloud）之后，脑子里面就会有一个疑问，像基于duubo+zookeeper（或者springcloud）这种分布式项目，本身就可以实现负载均衡的功能，那我们还需要nginx来做负载均衡吗？答案是显而易见的，那我们不仅就要问：nginx的负载均衡和分布式中自带的负载均衡有什么区别呢？

我们可以从他们特点来区分，他们的特点如下：

1.duubo+zookeeper动态注册就可以实现负载均衡，不需要做任何的配置，可以平滑的添加服务，但是并发能力不是特别强。

2.nginx中添加服务，必须添加配置文件才可以，不能动态的添加服务，但是nginx一是可以作为静态服务器，而是并发能力很强。

基于他们的特点，我们项目中采用后端服务器采用duubo+zookeeper进行负载均衡请求服务，app和web端入口采用nginx进行负载均衡。下面我们基于这种模式做深入的分析。

现在有这样的应用场景：我们为了这个项目买了多个服务器，但是我们为了保证服务器的高可用性，所有不想把一个系统按照功能划分放在一一对应的服务器上面，我们想一个服务器上面就放一个完整的应用系统，这样每一个服务器都有一份系统在运行，基于这种考虑我们就采用服务器内部采用duubo+zookeeper进行负载均衡，不同服务器之间采用nginx进行负载均衡。如下图所示：

应用升级：

升级一：因为项目是采用前后台分离的，所有必然会有一个个前端项目，这个前端项目我们不能放在后端服务器中一起部署，所以只能放在web类型的请求容器中，所以这边我们直接就将前端项目放在nginx中（利用nginx作为做静态服务器）。这样就又出现一个问题，不同类型的项目，它对应的的域名也不一样，但是对应的服务器却是同一个IP地址。所以基于这种情况，我们只需要采用nginx方向代理就可以完成了。

升级二：随着时间的推移，项目的用户量越来越多了，对项目的可靠性要求越来越大了。我们虽然可以不断增加duubo+zookeeper所部署的服务器，可是一旦nginx挂掉，整个系统将直接瘫痪，所以单例的nginx风险是特别高的。基于这种情况我们就必须采用多个nginx来平摊这种风险了，这边我们可以用lvs+nginx来实现这种多个nginx，架构图如下所示：

升级三：通过这种方式就可以完美的将这种问题解决了，可是这个问题并没有彻底的解决，还是存在很大的风险，如果lvs挂掉，整个项目还是会死掉，所以基于这种问题我们可以添加一个keepalive来热备份一个LVS。如下图所示：