之前写的负载均衡服务器项目，只能在启动时配置结点，运行状态时节点宕机倒是可以删除它。但是不能实时得检测节点信息，尤其是如果新增节点还要服务器重启重新配置，本文的 Zookeeper 给了我一个思路。
当服务越来越多，规模越来越大时，对应的机器数量也越来越大，单靠人工来管理和维护服务及地址的配置地址信息，已经很困难了，并且，依赖单一的硬件负载均衡设备或者使用LVS.nginx等软件方案进行路由和负载均衡调度，单点故障的问题也开始凸显，一旦服务路由或者负载均衡服务器宕机，依赖他的所有服务均将失效。
此时，需要一个能够动态注册和获取服务信息的地方。来统一管理服务名称和其对应的服务器列表信息，称之为服务配置中心，服务提供者在启动时，将其提供的服务名称、服务器地址注册到服务配置宗新，服务消费者通过服务配置中心来获得需要调用的服务的机器列表。通过相应的负载均衡算法，选取其中一台服务器进行调用。当服务器宕机或者下线时，相应的机器需要能够动态地从服务配置中心里面溢出，并通知相应的服务消费者，否则服务消费者就有可能因为调用到已经失效服务而发生错误，在这个过程中，服务消费者只有在第一次调用服务时需要查询服务配置中心，然后将查询到的信息缓存到本地，后面的调用直接使用本地缓存的服务地址列表信息，而不需要重新发起请求道服务配置中心去获取相应的服务地址列表，直到服务的地址列表有变更（机器上线或者下线）。这种无中心化的结构解决了之前负载均衡设备所导致的单点故障问题，并且大大减轻了服务配置中心的压力
基于Zookeeper的持久和非持久节点，我们能够近乎实时地感知到后端服务器的状态（上线、下线、宕机）通过集群间的zab协议，使得服务配置信息能够保持一致。而zookeeper本身容错特性和leader选举机制，能保障我们方便进行扩容，通过zookeeper来实现服务动态注册。机器上线和下线的动态感知，扩容方便，容错性好，且无中心化结构能够解决之前使用负载均衡设备所带来的单点故障问题，只有当配置信息更新时才会去zookeeper上获取最新的服务地址列表，其他时候使用本地缓存即可。
一旦服务器与zookeeper集群断开连接，节点也就不存在了，通过注册相应的watcher，服务消费者能够第一时间获知服务提供者机器信息的变更，利用其znode的特点和watcher机制，将其作为动态注册和获取服务信息的配置中心，统一管理服务名称和其对应的服务器列表信息，我们能够近乎实时地感知到后端服务器的状态（上线、下线、宕机）.zookeeper集群间通过zab协议，服务配置信息能够保持一致，而zookeeper本身容错特性和leader选举机制，能够保障我们方便的扩容。
