Dubbo + Zookeeper 浅析

Dubbo + zookeeper 是现在比较流行的架构，也是我们行部分系统正在使用的架构，例如支撑平台。下面就介绍一下为什么要使用这个架构和这个架构的工作流程。

Dubbo使用registry进行服务注册和订阅，当我们新增生产者服务时，只需要向注册中心注册便可，不同以往，需要修改消费者的配置文件才可以实现集群的扩展。

对于开发者来说，通过dubbo的框架，消费者和生产者在使用或提供服务时，只需要在配置文件里声明要使用或提供的服务，配上注册中心的配置，便可以使用和调用对应的服务，因此在消费者一侧，无需关心要调用哪台服务器的服务，IP、URL等等信息，调用远程接口的时候也不用像传统的new一个><dubbo:service/> 服务配置，用于暴露一个服务，定义服务的元信息，一个服务可以用多个协议暴露，一个服务也可以注册到多个注册中心。
eg、<dubbo:service ref="demoService" interface="comxxxxxxproviderDemoService" />

<dubbo:reference/> 引用服务配置，用于创建一个远程服务代理，一个引用可以指向多个注册中心。
eg、<dubbo:reference id="demoService" interface="comxxxxxxproviderDemoService" />

<dubbo:protocol/> 协议配置，用于配置提供服务的协议信息，协议由提供方指定，消费方被动接受。
eg、<dubbo:protocol name="dubbo" port="20880" />

<dubbo:application/> 应用配置，用于配置当前应用信息，不管该应用是提供者还是消费者。
eg、<dubbo:application name="provider" />

<dubbo:module/> 模块配置，用于配置当前模块信息，可选。
<dubbo:registry/> 注册中心配置，用于配置连接注册中心相关信息。
eg、<dubbo:registry address=" zookeeper://1921682249:2181 " />

<dubbo:monitor/> 监控中心配置，用于配置连接监控中心相关信息，可选。
<dubbo:provider/> 提供方的缺省值，当ProtocolConfig和ServiceConfig某属性没有配置时，采用此缺省值，可选。
<dubbo:consumer/> 消费方缺省配置，当ReferenceConfig某属性没有配置时，采用此缺省值，可选。
<dubbo:method/> 方法配置，用于ServiceConfig和ReferenceConfig指定方法级的配置信息。
<dubbo:argument/> 用于指定方法参数配置。

Invoker URL ServiceBean

URL 之于 Dubbo，犹如水之于鱼，非常重要。

在 Dubbo 中，Invoker 是一个非常重要的模型。在服务提供端，以及服务引用端均会出现 Invoker。Dubbo 官方文档中对 Invoker 进行了说明，这里引用一下。

Invoker 是实体域，它是 Dubbo 的核心模型，其它模型都向它靠扰，或转换成它，它代表一个可执行体，可向它发起 invoke 调用，它有可能是一个本地的实现，也可能是一个远程的实现，也可能一个集群实现。

1概览

>

 假设zookeeper安装在17216222这台服务器上,现在我们通过命令行查看dubbo在zookeeper注册服务的生产者和消费者信息

首先通过命令切换到/zookeeper-3411/bin目录,然后输入

(2182为zookeeper在服务器上提供服务的端口)会看到如下截图:

然后在命令行再输入:

查看目录信息,就能看到注册的dubbo服务,截图如下:

在命令行依次输入:

会看到dubbo服务提供的对外接口,截图如下:

查看消费者命令:

会看到消费者的信息,截图如下:

查看生产者命令:

会看到生产者的信息，截图如下：

dubbo 是一个远程调用服务的分布式框架，可以实现远程通讯、动态配置、地址路由等等功能。比如在入门demo里的暴露服务，使得远程调用的协议可以使用dobbo协议( dubbo://xxxx )或者其它协议，可以配置zookeeper集群地址，实现软负载均衡并配置均衡方式等。在不搭配注册中心的时候，它也是可以实现服务端和调用端的通信的，这种方式是点对点通信的，所谓“没有中间商”。但是如果配置服务发布和调用端过多特别是集群的方式提供服务的时候，就会暴露许多的问题：增加节点需要修改配置文件、服务端机器宕机后不能被感知等。它可以通过集成注册中心，来动态地治理服务发布和服务调用。相当于把服务注册和发布推送的功能分摊给了(zookeeper)注册中心。

Dubbo实现服务调用是通过RPC的方式，即客户端和服务端共用一个接口(将接口打成一个jar包，在客户端和服务端引入这个jar包)，客户端面向接口写调用，服务端面向接口写实现，中间的网络通信交给框架去实现。

咱们来看下Spring 配置声明暴露服务，providerxml文件

再来看服务消费者，consumerxml文件

这就是典型的点对点的服务调用。当然我们为了高可用，可以在consumerxml中配置多个服务提供者，并配置响应的负载均衡策略。

配置多个服务调用者在comsumerxml的dubbo:reference标签的url属性中加入多个地址，中间用分号隔开即可；配置负载均衡策略在comsumerxml的dubbo:reference标签中增加loadbalance属性即可，值可以为如下四种类型：

那么目前的架构有什么问题呢？
1当服务提供者增加节点时，需要修改配置文件。
2当其中一个服务提供者宕机时，服务消费者不能及时感知到，还会往宕机的服务发送请求。

这个时候就需要引入注册中心了，Dubbo目前支持4种注册中心(multicast、zookeeper、redis、simple)推荐使用Zookeeper注册中心，要使用注册中心，只需要将providerxml和consumerxml更改为如下：

如果zookeeper是一个集群，则多个地址之间用逗号分隔即可

把consumerxml中配置的直连的方式去掉

注册信息在zookeeper中如何保存？
启动上面服务后，我们观察zookeeper的根节点多了一个dubbo节点及其他，图示如下

最后一个节点中服务的地址，为什么把最后一个节点标成绿色？因为最后一个节点是临时节点，而其他节点是持久节点，这样，当服务宕机时，这个节点就会自动消失，不再提供服务，服务消费者也不会再请求。如果部署多个DemoService，则providers下面会有好几个节点，一个节点保存一个DemoService的服务地址。
其实一个zookeeper集群能被多个应用公用，因为不同的框架会在zookeeper上建不同的节点，互不影响。如dubbo会创建一个/dubbo节点，storm会创建一个/storm节点。

zookeeper 介绍：
zookeeper是 Apacahe Hadoop 的子项目，是一个树型的目录服务，支持变更推送，适合作为 Dubbo 服务的注册中心，工业强度较高，可用于生产环境，并推荐使用。

流程说明：

支持以下功能：

补充：
dubbo的协议使用什么序列化框架？
dubbo有多种协议，不同的协议默认使用不同的序列化框架。比如dubbo协议默认使用 Hessian2 序列化(说明：Hessian2 是阿里在 Hessian 基础上进行的二次开发，起名为Hessian2)。rmi协议默认为 java 原生序列化，>近期由于搭建公司整套测试环境中使用Docker 容器化部署Dubbo一直出现找不到服务提供者
经过两天断断续续的摸索以及资料（说到这理要落泪了）的查询该问题得意解决这就是本次要扯的内容。

本次 dubbo 服务 是以docker-compose进行服务编排部署，服务者与消费者也在同一个Java 工程目录下

当我们服务者工程开启的时候会在Nacos中服务列表中产生新的一项接口其内容是这样的，根据下方的可以很清楚的看到IP及端口是不是有点似曾相识的感觉呢，特别是20880端口！
又经历了一资料的查询之后，我发现20800端口并没有被我映射出来。于是我把服务提供者配置文件改这样：

消费者配置文件改成这样

终于在我本地以及不同的服务器之间可以正常运行了！

其实如果不在测试环境上遇到这些问题以后在生产环境上也同样会遇到，我们能做的就是在问题到来之前做一定的知识储备避免一些常见的坑。

---