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