Nginx/ZooKeeper 负载均衡的差异

• Nginx 是我们常见的反向代理服务器，也被广泛的用作负载均衡服务器
• ZooKeeper是分布式协调服务框架，有时也被用来做负载均衡

Nginx

• Nginx负载均衡配置非常简单，吧多个Web Server配置到nginx中，用户访问Nginx时候，会自动被分配到某个webServer，如下Nginx配置：

upstream backend{
server1 192.168.1.10;
server2 129.168.1.11;
}

• 当网证规模变大，通常进行服务拆分，各个服务独立部署，通过远程调用方式协同工作，如下示意图：
  
• 为保证稳定性，每个服务不会用一台服务器，也会做集群，你们这子集群同样需要一个负载均衡，可以使用Nginx
  
• 到这一步我们用Nginx完全可以解决问题，但是随着系统再次增大，服务数量也会增加，每个服务集群服务器数据增加，这个时候会有如下问题：
  • 维护Nginx配置的成本变大，节点变多
  • 单点故障风险增加，因为热点服务，比如用户信息，访问量高，如果这个服务器集群的Nginx出现问题，服务将失效
• 第一个问题，可以自己开发插件解决，只是降低复杂度，没有根本解决。
• 第二个问题，可以通过多Nginx部署方案，另一台Nginx可以待命状态，提高容错，只是增加成本

Zookeeper负载均衡实现思路

• 将Zookeeper作为服务注册中心，在其中登记每个服务，每台服务器指定自己是属于那个服务，在服务启动时候，想所属服务进行注册，这样一个树形服务结构就呈现出来：
  
• 服务调用者到注册中心查找：能提供所需服务的服务列表，然后自己根据负载均衡算法，从中选取一台服务器进行连接，并且在此节点注册watcher，修改通知
• 调用者渠道服务列表，可以缓存在自己内部，省的下次在获取，当服务器列表发送变化，例如宕机，或添加新的服务器，Zookeeper的watcher机制会通知添加修改关注的调用者重新获取服务器列表
• 此处只是利用了Zookeeper树形数据结构，watcher机制等性能，吧Zookeeper作为服务注册和变更通知，解决了Nginx负载均衡方案带来的问题

总结

zookeeper	nginx
不存在单点问题，zab机制保证单点故障可重新选举一个leader	存在单点问题，单点负载高数据量大
只负责服务的注册与发现，不负责转发，减少一次数据交换（消费方与服务方直接通信）	每次负载，都充当一次中间人转发角色，增加网络负载量（消费方与服务方间接通信）
需要自己实现相应的负载均衡算法	自带负载均衡算法

上一篇Zookeeper实践与应用- Canal
下一篇Zookeeper–分布式锁