Nginx是著名的反向代理服务器,也被广泛的作为负载均衡服务器
ZooKeeper是分布式协调服务框架,有时也被用来做负载均衡
那么他们的区别是什么?如何选择呢?
下面从实际场景看下他们的关系
Nginx的负载均衡配置非常简单,把多个web server配置到nginx中,用户访问Nginx时,就会自动被分配到某个web server
upstream backend {
server 192.168.1.10;
server 192.168.1.11;
当网站规模变大,通常会进行服务拆分,各个服务独立部署,通过远程调用方式协同工作
为了保证稳定性,每个服务不会只使用一台服务器,也会作为一个集群存在,那么这个子集群同样需要一个负载均衡器,可以使用Nginx
到这里还是没有感觉有使用ZooKeeper的必要,因为使用Nginx完全没问题
但随着整个系统的演进, 服务 的数量会 增加 、每个服务集群中的 服务器 数量会增加
这时就会有一些小麻烦,例如
(1)配置维护的成本变高,因为节点太多
(2)单点故障的风险增加了,因为热点服务的访问量很高,如果这个服务集群内的负载均衡服务出现问题,这个服务将失效
第一个问题,可以通过自己开发程序解决,但只是降低复杂度,并没有实际解决
第二个问题,可以通过双机高可用部署方案,使用另一台nginx负载均衡服务器随时待命,只是成本较高
为了解决这些问题,就有人提出了使用ZooKeeper负载均衡的方案,之前就看到淘宝介绍过此类方案
ZooKeeper负载均衡的实现思路
把ZooKeeper作为一个服务的注册中心,在其中登记每个服务,每台服务器知道自己是属于哪个服务,在服务器启动时,自己向所属服务进行登记,这样,一个树形的服务结构就呈现出来了
服务的调用者到注册中心里面查找:能提供所需服务的服务器列表,然后自己根据负载均衡算法,从中选取一台服务器进行连接
调用者取到服务器列表后,就可以缓存到自己内部,省得下次再取,当服务器列表发生变化,例如某台服务器宕机下线,或者新加了服务器,ZooKeeper会自动通知调用者重新获取服务器列表
由于ZooKeeper并没有内置负载均衡策略,需要调用者自己实现,这个方案只是利用了ZooKeeper的树形数据结构、watcher机制等特性,把ZooKeeper作为服务的注册和变更通知中心,解决了Nginx负载均衡方案带来的问题
转载:https://blog.csdn.net/yongche_shi/article/details/51514131