Dubbo分布式服务框架--学习二 Dubbo和Zookeeper关系

学习dubbo和那必须先要了解Dubbo和Zookeeper关系

您可以把dubbo服务想象成学校里的一个学生，并且对应有一个学号，zookeeper则是想象成一个教务网管理系统。我们可以通过教务网管理系统，查找到对应的学生。我们首先通过注册入学，将学生和学号对应绑定。

比方说项目是一个分布式的项目，web层与 service层被拆分了开来， 部署在不同的tomcat中， 我在web层 需要调用 service层的接口，但是两个运行在不同tomcat下的服务无法直接互调接口，那么就可以通过zookeeper和dubbo实现。

我们通过dubbo 建立ItemService这个服务，并且到zookeeper上面注册，填写对应的zookeeper服务所在 的IP及端口号。【按照我上面的比喻就是，学生注册入学（接口是学号，学生本人是impl实现），填写学校教务网网址（就是zookeeper）】

下面我们的 web层需要来调用 service接口了，由于在不同的工程中，它是无法直接找到service接口的，我们使用dubbo再来引用注册进入的dubbo服务。

我们先填写zookeeper服务所在的IP及端口号，再填写我们需要调用的接口名字。

【按照我上面的比喻，就是填写学校的教务网网址，我们在教务网中，通过学号（接口名），查询到对应的学生】

这样就能实现简单调用.

 

zookeeper实现的是资源的订阅发布基本原理就是，分布式的环境下服务方实际上是资源，每个服务方把自己的服务的节点信息，注册在zk上，消费者通过zk获取到所需要的服务的相关信息，比如url之类。

但是zk有个很重要的功能，会主动通知消费者所订阅资源的变化信息，比如，同一个服务某台机器相关进程关闭后，zk会通知消费者，资源的变化情况，这样，就实现了服务的动态添加减少。

这一点在分布式环境下非常重要，设想如下场景

某网站在做抢购活动，突然发现，后台某个服务资源吃紧，需要增加服务器，而又不能影响当前业务，

简单来说他的功能类似于注册中心。

dubbo的服务提供者会在zookeeper上面创建一个临时节点，表明自己的IP和端口，当消费者需要使用服务时，会先在zookeeper上面查询，找到服务提供者，做一些负载的选择（比如随机、轮流），然后按照这些信息，访问服务提供者。

zookeeper负责保存了服务提供方和服务消费方的的URI（dubbo自定义的一种URI），服务消费方找到zookeeper，向zookeeper要到服务提供方的URI，然后就找到提供方，并调用提供方的服务。解耦，分布式，failover。

dubbo是管理中间层的工具，在业务层到数据仓库间有非常多服务的接入和服务提供者需要调度，dubbo提供一个框架解决这个问题。

注意这里的dubbo只是一个框架，至于你架子上放什么是完全取决于你的，就像一个汽车骨架，你需要配你的轮子引擎。这个框架中要完成调度必须要有一个分布式的注册中心，储存所有服务的元数据，你可以用zk，也可以用别的，只是大家都用zk。

 

zookeeper用来注册服务和进行负载均衡，哪一个服务由哪一个机器来提供必需让调用者知道，简单来说就是IP地址和服务名称的对应关系。当然也可以通过硬编码的方式把这种对应关系在调用方业务代码中实现，但是如果提供服务的机器挂掉调用者无法知晓，如果不更改代码会继续请求挂掉的机器提供服务。zookeeper通过心跳机制可以检测挂掉的机器并将挂掉机器的IP和服务对应关系从列表中删除。至于支持高并发，简单来说就是横向扩展，在不更改代码的情况通过添加机器来提高运算能力。通过添加新的机器向zookeeper注册服务，服务的提供者多了能服务的客户就多了。

结构大致分为三层：1.facade层（伪注册中心层）、2.services层、3.web层。

1.facade层，主要是在zookeeper注册中心中需要注册的服务和暴露的接口、dto、entity

2.services层，主要是实现接口的具体业务逻辑，我们称之为biz，和与数据库进行交互操作的dao

3.web层，主要是jsp页面和controller，以及一些css样式和js文件

项目的大体流程是这样的，在facade层中注册（写好）需要暴露的接口，这些接口在services层中具体实现业务逻辑，web层中jsp页面请求controller中的方法，controller调用facade中的接口，这里可以理解为web层发出请求后去注册中心里查询这个服务接口是否已经注册并且有相应的服务提供者，如果有，注册中心会将实现该服务的service的url返回给web层，这样wb层去访问注册中心返回来的url地址，也就是services层中具体的实现方法，services将操作后的结果返回给web层，这样下来一套流程算是走完。其中，dto用在网络数据传输层中，这并不是实体，只是根据controller需要的字段有选择的创建的类，而entity不出现在网络数据传输层中，它只在dao层中与数据库交互，在前台请求中的参数由dto或者基本类型来承载，所以传递到services层中的参数并不是实体，所以，一般在这里将dto中的数据copy到实体中，再由实体与数据库进行操作。这样实体的属性和结构并不会暴露出去，保证了项目的安全行，而且用dubbo和zookeepe搭建的分布式项目（并不是说dubbo和zookeeper这俩很强，springcloud也是分布式的框架，只是将分布式的项目和单点项目做一个比较），安全性要比一般的单点项目要高，因为分布式的项目暴露在外网的只是web层中页面的访问地址，对于后面的返回的service的url和具体的操作是在内网环境中配置的，没有直接的物理操作，安全性是极高的。而且，分布式项目可有很多个services层和web层，也是可以解决高并发和产品版本冲突。上传的内容的挺乱的，如果配着前面写的解释看应该可以看明白一点。

转载链接：https://www.zhihu.com/question/25070185/answer/227169884

转载链接：http://blog.csdn.net/shiyus1314/article/details/77500780