Nginx/ZooKeeper 负载均衡的差异

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负载均衡方案带来的问题