zookeeper服务注册中心&负载均衡

Nginx VS 软负载均衡

nginx作为作为传统的负载均衡器，通过简单的配置即可完成负载均衡器的配置，单台nginx作为负载均衡器还存在单点故障(SPOF)问题，对应nignx的单点故障，通常采用nginx+keepalive的方式做双机热备份，客户端通过vip访问后端服务，当单台nignx宕掉的时候，vip漂移到另一台nginx以此实现nginx高可用。那么使用nignx作为负载均衡器有哪些缺点呢？

1. 负载均衡策略简单。当前支持轮询，权重，ip绑定，fair，url_hash，对于动态权重调节，服务降级不能很好支持

2. 蓝绿部署支持困难。比如新上线一个功能，可能需要引流特定的账号体现新功能，此时可以用如下方式满足要求

   • 通过将新账号信息加入到http头中，按照head中的用户信息分流到带新功能的节点上，此方案显然需要人工参与，或用自动化脚本实现
   • 通过nginx+lua+redis方式。将需要引流的用户放到redis中，当请求过来后通过方式1获取到用户信息，然后通过lua脚本在redis中查询是否存在该用户，如果存在，则将该用户引流到带新功能的节点上

3. 应用级自动failover难以实现

   通过上面两种方法可以发现，虽然可以达到目的，但过程繁琐，特别是系统采用微服务架构方式后，问题更明显

软负载均衡

所谓软负载均衡就是通过软件的方式实现类似nginx的功能。需要一个服务注册中心，需满足如下几点

1. 一个统一的注册中心支持将服务注册上去
2. 当后端服务不再健康时，能够自动从注册中心注销掉该服务
3. 注册中心需要具备反向通知的能力，能够实时监控服务健康状态
4. 支持高可用

实际上光有注册中心还不过，试想如果每次客户端访问后端服务都需要到注册中心去查询服务列表，在高并发场景下注册中心不就成为了性能瓶颈点。所以还需要在客户端做点功能

1. 客户端因缓存下服务列表，当某个服务实例宕掉后，利用注册中心反向通知能力刷新本地缓存
2. 支持不同的负载均衡策略
3. failover支持，当调用某个接口失败时可自动切换到下一个节点

满足上面几个条件后基本上就可以实现一个简单功能的软负载均衡器了，可以看出软负载均衡器由于使用代码方式实现，以后扩展灵活，想加一个负载均衡策略加上就完事了，想做蓝绿可以开发一个服务注册中心管理器，通过反向通知，通知服务下线。想做蓝绿升级，滚动升级，也可以在注册中心管理器中安装下线升级上线的流程完成蓝绿部署或滚动升级

zookeeper软负载均衡

将了这个多，软负载均衡和zookeeper有什么关系呢？细心的朋友可以发现完全可以用zookeeper实现实现一个这样的注册中心，通过zookeeper的临时节点和session长连接就可以实现反向通知和服务宕机后自动下线和通知功能。

lb.png

那么用zookeeper作为负载均衡会不会有缺点呢？
zookeeper是一个CP,也就是说当网络分区发生时，分区内的机器如果没有过半，那么该分区实际是整个down掉了，该分区内的负载均衡和服务注册中心全over了，服务不可用了，所以这个时候可以使用本地缓存，或者爱用AP模型的注册中心，如euraka