dubbo 选用zookeeper的缘由

dubbo主要是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。简单的说，dubbo就是个服务框架，若是没有分布式的需求，实际上是不须要用的，只有在分布式的时候，才有dubbo这样的分布式服务框架的需求，而且本质上是个服务调用的东东，说白了就是个远程服务调用的分布式框架（告别Web Service模式中的WSdl，以服务者与消费者的方式在dubbo上注册） 
来个图片就简单明了 
 
上图是传统方式的，假如我有四台服务器，每台服务器都提供相同的服务，若是我消费者去掉用的时候，确定要在四个当中选择某一个去调用，但是选择哪个就是一个难题，固然这就涉及到负载均衡问题了，需用到F5(其实我也没用过F5。。。)或者咱们在消费者这边加代码逻辑判断达到负载均衡的效果，还有每次调用的时候都要查询当前有哪些服务提供者，这是很耗开销的。

方案都是一步一步进化的。 

咱们在消费者和服务提供者之间加了一层服务路由。服务路由提供F5功能同事还提供代理服务的地址，代理地址是稳定的，这样就算服务提供者地址改变了，消费者直接调用代理服务器地址给 服务器路由，让服务器路由本身去查询，减少开销

最终方案

咱们利用zookeeper生成的节点树，服务器提供者在启动的时候，将提供的服务名称和地址以节点的方式注册都服务器zookeeper服务器配置中心，消费者经过服务器配置中心获取须要的服务名称节点下的服务地址。由于znode有非持久节点的特性，服务器能够动态的从服务配置中心一处，而且触发消费者的watcher方法！！！ 
消费者只有在第一次调用的时候直接本地缓存服务器列表信息，而不需哟从新发起请求到服务器配置中心区获取相应 的服务器列表，直到服务器地址列表有变化（机器下线或者上线），变动厨房消费者watcher进行服务地址的从新查询。正是由于赭红无中心化的结构，使得服务消费者在服务信息没变动时候，几乎不依赖配置中心，解决了负载均衡设备致使的单点故障的问题，大大奖励了服务配置中心的压力