分布式项目中Nginx应用场景研究
众所周知nginx一般有两个作用,一个是负载均衡、一个反向代理。但是自从接触了duubo+zookeeper(或者springcloud)之后,脑子里面就会有一个疑问,像基于duubo+zookeeper(或者springcloud)这种分布式项目,本身就可以实现负载均衡的功能,那我们还需要nginx来做负载均衡吗?答案是显而易见的,那我们不仅就要问: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。如下图所示:
lvs+keepalive+nginx的参考文章可以参见:
https://www.cnblogs.com/yxy-linux/p/5744187.html
想要更多干货、技术猛料的孩子,快点拿起手机扫码关注我,我在这里等你哦~
更多推荐
已为社区贡献27条内容
所有评论(0)