zookeeper在dubbo中干什么

本文旨在表述出本身对于zookeeper在dubbo的做用的初步理解

在对dubbo进行了初步的探索后，对于zookeeper在其中的做用不甚了解，由于自己对zookeeper就没有一个特别具体的概念，因此在这里思考一下，为何要使用zookeeper或者说dubbo为何要有注册中心

 

一对一的调用

Server A依赖Server B提供的RPC服务，由于Server B只有单一的一份，那么此时Server A只须要Server B提供RPC调用的ip和port就能够了

一对多的调用

Server B在用户量日益扩大的背景下，须要进行横向扩展，此时的Server B扩充到了3台服务器：01，02，03

这样作的好处是：

• 一台宕机，还有两个正常运转的Server
• 负载均衡(并非zookeeper实现的，具体的负载均衡算法须要本身实现，zookeeper能提供给咱们的是可用服务列表)
• ...

那么对于Server A来讲，一会儿有3个Server B可使用，该如何选择呢？若是我选择了01，我还须要去关心，01是否是挂了，01挂了我选择谁呢？

对于Server B来讲，我如何进行负载均衡呢？

其实对于Server A来讲，我不想要关心Server B的主备状况，我但愿Server B的整个分布对于我这个调用方是彻底透明的，那么考虑一下这种结构：

其实这个结构很好理解：因为Server B的分布式部署，Server A有选择困难症不知道该选择哪个B，那么咱们就让中间人帮他选并告诉他，而后Server A知道要找谁了，就会去找相关的Server。图中黄色的线表明了注册通知过程，绿色的线表明了调用过程。

例如，Server B的3台服务器都注册一个“获取用户列表”的RPC接口到zookeeper中，Server A做为客户端链接zookeeper，向zookeeper讨要一个“获取用户列表”接口，拿到这个接口的相关信息以后，Server A再去调用具体的Server B的某一台服务器上的服务。即：注册中心（zookeeper）不作实际的方法调用，只作相关信息的传递者。

 

更多须要关注的细节：

• dubbo的在向zookeeper注册服务时，放了些什么数据进去？
• dubbo的负载均衡是dubbo本身作的，仍是zookeeper作的？
• ...