dubbo为什么用到了zookeeper

约定不等于承诺〃 2022-05-23 04:45 184阅读 0赞

有时候一些名词的出现自然有他的理由，千万不要忽视，有可能把这些名词串起来，你就通了哈哈。

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

方案都是一步一步进化的。   
![这里写图片描述][20150702122706625]

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

最终方案

![这里写图片描述][20150702124153865]

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

# dubbo为什么用到了zookeeper #

2015年07月02日 12:53:14

阅读数：10857

有时候一些名词的出现自然有他的理由，千万不要忽视，有可能把这些名词串起来，你就通了哈哈。

方案都是一步一步进化的。   
![这里写图片描述][20150702122706625]

最终方案

![这里写图片描述][20150702124153865]

[Link 1]: http://blog.csdn.net/ggjlvzjy/article/details/46709059
[20150702114116123]: /images/20220523/f8bac8cf8a9b4f09b46e585f25535c7e.png
[20150702122706625]: /images/20220523/98a911430e524edfba5cdba84d2c7181.png
[20150702124153865]: /images/20220523/bb099c29866941f58528c048849d5992.png