前面几篇文章说了很多ZooKeeper的功能特性，ZooKeeper是一个分布式应用下的分布式、开源的协调服务。说了那么多，那么到底在实际开发中，ZooKeeper是怎么提供服务的呢？这篇文章小段就简单讲述一下ZooKeeper在dubbo中的应用，作为驱动学习ZooKeeper的案例。
众所周知，dubbo是阿里巴巴开源的一个分布式服务治理框架，既然是服务是分布式的、分散的，那么如果服务提供方较多（比如100个），而且这些服务又分散在不同的机器上，这时如果每个服务调用方都把这些服务提供方的地址写入到配置文件，那么这100个服务部分机器宕机，那么就需要把所有的服务调用方的配置文件修改并重启服务，这就严重影响了系统的稳定性。
但是，使用ZooKeeper作为注册中心，每个服务提供方启动时都把自己的信息注册到注册中心（ZooKeeper），反之，如果服务提供方宕机或者重启则取消注册，由于ZooKeeper的临时节点特性和消息通知特性，注册中心的数据也能保持最新。节点消失时，服务调用方也能及时收到通知，并及时更新服务提供者列表。这样就保证了服务的负载均衡，也能防止单一应用的单点故障问题。这就是dubbo的注册中心的基本原理的通俗说法。至于，dubbo是如何实现rpc远程调用的，原理也很简单，但由于不是本文的内容，在这里就不做阐述。
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
