有时候一些名词的出现自然有他的理由，千万不要忽视，有可能把这些名词串起来，你就通了哈哈。
上一篇博文企业服务总线提到了关于服务的提供者和服务的消费者之间的调度解决方案。
dubbo主要是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。简单的说，dubbo就是个服务框架，如果没有分布式的需求，其实是不需要用的，只有在分布式的时候，才有dubbo这样的分布式服务框架的需求，并且本质上是个服务调用的东东，说白了就是个远程服务调用的分布式框架（告别Web Service模式中的WSdl，以服务者与消费者的方式在dubbo上注册）
来个图片就简单明了 
上图是传统方式的，假如我有四台服务器，每台服务器都提供相同的服务，如果我消费者去掉用的时候，肯定要在四个当中选择某一个去调用，可是选择哪一个就是一个难题，当然这就涉及到负载均衡问题了，需用到F5(其实我也没用过F5。。。)或者我们在消费者这边加代码逻辑判断达到负载均衡的效果，还有每次调用的时候都要查询当前有哪些服务提供者，这是很耗开销的。
方案都是一步一步进化的。
我们在消费者和服务提供者之间加了一层服务路由。服务路由提供F5功能同事还提供代理服务的地址，代理地址是稳定的，这样就算服务提供者地址改变了，消费者直接调用代理服务器地址给 服务器路由，让服务器路由自己去查询，减小开销
最终方案
我们利用zookeeper生成的节点树，服务器提供者在启动的时候，将提供的服务名称和地址以节点的方式注册都服务器zookeeper服务器配置中心，消费者通过服务器配置中心获取需要的服务名称节点下的服务地址。因为znode有非持久节点的特性，服务器可以动态的从服务配置中心一处，并且触发消费者的watcher方法！！！
消费者只有在第一次调用的时候直接本地缓存服务器列表信息，而不需哟重新发起请求到服务器配置中心区获取相应 的服务器列表，直到服务器地址列表有变化（机器下线或者上线），变更厨房消费者watcher进行服务地址的重新查询。正是因为赭红无中心化的结构，使得服务消费者在服务信息没变更时候，几乎不依赖配置中心，解决了负载均衡设备导致的单点故障的问题，大大奖励了服务配置中心的压力
dubbo为什么用到了zookeeper
有时候一些名词的出现自然有他的理由，千万不要忽视，有可能把这些名词串起来，你就通了哈哈。
上一篇博文企业服务总线提到了关于服务的提供者和服务的消费者之间的调度解决方案。
dubbo主要是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。简单的说，dubbo就是个服务框架，如果没有分布式的需求，其实是不需要用的，只有在分布式的时候，才有dubbo这样的分布式服务框架的需求，并且本质上是个服务调用的东东，说白了就是个远程服务调用的分布式框架（告别Web Service模式中的WSdl，以服务者与消费者的方式在dubbo上注册）
来个图片就简单明了
上图是传统方式的，假如我有四台服务器，每台服务器都提供相同的服务，如果我消费者去掉用的时候，肯定要在四个当中选择某一个去调用，可是选择哪一个就是一个难题，当然这就涉及到负载均衡问题了，需用到F5(其实我也没用过F5。。。)或者我们在消费者这边加代码逻辑判断达到负载均衡的效果，还有每次调用的时候都要查询当前有哪些服务提供者，这是很耗开销的。
方案都是一步一步进化的。
我们在消费者和服务提供者之间加了一层服务路由。服务路由提供F5功能同事还提供代理服务的地址，代理地址是稳定的，这样就算服务提供者地址改变了，消费者直接调用代理服务器地址给 服务器路由，让服务器路由自己去查询，减小开销
最终方案
我们利用zookeeper生成的节点树，服务器提供者在启动的时候，将提供的服务名称和地址以节点的方式注册都服务器zookeeper服务器配置中心，消费者通过服务器配置中心获取需要的服务名称节点下的服务地址。因为znode有非持久节点的特性，服务器可以动态的从服务配置中心一处，并且触发消费者的watcher方法！！！
消费者只有在第一次调用的时候直接本地缓存服务器列表信息，而不需哟重新发起请求到服务器配置中心区获取相应 的服务器列表，直到服务器地址列表有变化（机器下线或者上线），变更厨房消费者watcher进行服务地址的重新查询。正是因为赭红无中心化的结构，使得服务消费者在服务信息没变更时候，几乎不依赖配置中心，解决了负载均衡设备导致的单点故障的问题，大大奖励了服务配置中心的压力