spring Boot环境下dubbo+zookeeper的一个基础讲解与示例

一，学习背景

1.   前言

对于我们不管工作还是生活中，需要或者想去学习一些东西的时候，大致都考虑几点：

a)      我们为什么需要学习这个东西？

b)     这个东西是什么？

c)      这个东西能为我们做什么？

d)     如何去学？

结合以上几点，我们一起学习下dubbo这个框架！

2.   学习背景

互联网的发展，网站应用的规模不断扩大，常规的垂直应用架构已无法应对，分布式服务架构以及流动计算架构势在必行，dubbo是一个分布式服务框架，在这种情况下诞生的。现在核心业务抽取出来，作为独立的服务，使前端应用能更快速和稳定的响应。

3.   dubbo是什么

dubbo是alibaba开源的分布式服务框架，它最大的特点是按照分层的方式来架构，使用这种方式可以使各个层之间解耦合（或者最大限度地松耦合）。从服务模型的角度来看，dubbo采用的是一种非常简单的模型，要么是提供方提供服务，要么是消费方消费服务，所以基于这一点可以抽象出服务提供方（provider）和服务消费方（consumer）两个角色。关于注册中心、协议支持、服务监控等内容

4.   dubbo能做什么

当网站变大后，不可避免的需要拆分应用进行服务化（微服务），以提高开发效率，调优性能，节省关键竞争资源等。 
当服务越来越多时，服务的url地址信息就会爆炸式增长，配置管理变得非常困难，f5硬件负载均衡器的单点压力也越来越大。 
当进一步发展，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。 
接着，服务的调用量越来越大，服务的容量问题就暴露出来，这个服务需要多少机器支撑？什么时候该加机器？等等…… 
在遇到这些问题时，都可以用dubbo来解决。

5.   如何去学习dubbo

百度搜索dubbo

a)        官网： 去查看关于dubbo的官方定义，了解这是个什么东西。

b)       dubbo框架设计者的专访：看一下阿里巴巴人士如何评价dubbo的。

c)        dubbo的入门使用：

d)       dubbo框架的详解与原理：看不懂就先会用。

二，开启学习之路

1.   dubbo架构图

总体设计架构：

 

基础架构：

 

上图中，蓝色的表示与业务有交互，绿色的表示只对dubbo内部交互。上述图所描述的调用流程关系如下：

0. 服务容器负责启动，加载，运行服务提供者，这个图上没标识出来，服务端启动就是0.

1. 服务提供者在启动时，向注册中心注册自己提供的服务。

2. 服务消费者在启动时，向注册中心订阅自己所需的服务。

3. 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。

4. 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。

5. 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。

2.   dubbo与zookeeper

dubbo为什么要与zookeeper/consule一起使用？

dubbo主要是一个分布式服务框架，致力于提供高性能和透明化的rpc远程服务调用方案，以及soa服务治理方案。简单的说，dubbo就是个服务框架，如果没有分布式的需求，其实是不需要用的.告别web service模式中的wsdl，以服务者与消费者的方式在dubbo上注册.

zookeeper用来注册服务和进行负载均衡，哪一个服务由哪一个机器来提供必需让调用者知道，简单来说就是ip地址和服务名称的对应关系。zookeeper通过心跳机制可以检测挂掉的机器并将挂掉机器的ip和服务对应关系从列表中删除。

看图识物：

 

上图所示，假如我有四台服务器，每台服务器都提供相同的服务，如果我消费者去掉用的时候，肯定要在四个当中选择某一个去调用，可是选择哪一个就是一个难题，当然这就涉及到负载均衡问题了，或者我们在消费者这边加代码逻辑判断达到负载均衡的效果。还有每次调用的时候都不知道要去掉哪个服务，都要查询当前有哪些服务提供者，这是很耗开销的，当服务提供越来越多的时候，越来越乱。

最终方案：

 

利用zookeeper生成的节点树，服务器提供者在启动的时候，将提供的服务名称和地址以节点的方式注册都服务器zookeeper服务器配置中心，消费者通过服务器配置中心获取需要的服务名称节点下的服务地址。因为znode有非持久节点的特性，服务器可以动态的从服务配置中心一处，并且触发消费者的watcher方法！！！

消费者只有在第一次调用的时候直接本地缓存服务器列表信息，而不需要重新发起请求到服务器配置中心区获取相应 的服务器列表，直到服务器地址列表有变化（机器下线或者上线），变更之后消费者watcher进行服务地址的重新查询。正是因为这种无中心化的结构，使得服务消费者在服务信息没变更时候，几乎不依赖配置中心，解决了负载均衡设备导致的单点故障的问题，大大减少了服务配置中心的压力 

3.    zookeeper的安装

此处以windows环境下为例

注：linux安装参考

在apache的官方网站提供了好多镜像下载地址，然后找到对应的版本，目前最新的是3.3.6

下载地址：

把下载的zookeeper的文件解压到指定目录

 

修改conf下增加一个zoo.cfg

内容如下：

# the number of milliseconds of eachtick  心跳间隔毫秒每次

ticktime=2000

# the number of ticks that the initial

# synchronization phase can take

initlimit=10

# the number of ticks that can pass between

# sending a request and gettinganacknowledgement

synclimit=5

# the directory where the snapshotisstored.  //镜像数据位置

datadir=d:\\data\\zookeeper

#日志位置

datalogdir=d:\\logs\\zookeeper

# the port at which the clientswillconnect  客户端连接的端口

clientport=2181

注：如果启动有报错提示cfg文件有错误，可以用zoo_sample.cfg内内容替代也是可以的

进入到bin目录，并且启动zkserver.cmd，这个脚本中会启动一个java进程

这个时候zookeeper已经安装成功了.

4.  配置dubbo-admin的管理页面

下载dubbo-admin-2.4.1.war包，解压到tomcat中。

如图所示：

 

修改dubbo.properties文件，里面指向zookeeper ，使用的是zookeeper 的注册中心。

然后启动tomcat服务，用户名和密码：root,并访问服务，显示登陆页面，说明dubbo-admin部署成功，如图所示：

目前我们还没有注册服务，所以内容都是空的。

5.   程序演示

现在我们来看个简单的dubbo-demo项目，此项目只分解了两个工程，一个服务提供者，一个消费者。此项目只适用于演示使用。因为，你在非分布式的项目上使用dubbo，多此一举。

如图：

 

6.   服务提供者

演示工程结构如下：

 

首先看下咱们的pom文件，引入dubbo和zookeeper的jar包.没啥好说的。

 

然后我们写自己的接口与实现，通常分布式设计下接口应该与实现分开，让接口与bean单独起工程模块，以便服务提供者与消费者都可以调用。如果服务端有自己不暴漏的方法，可单写接口类，也可中间加层，看业务而定。

 

重点看下我们dobbo配置

 

属性说明：

   dubbo:registry 标签一些属性的说明：

a)        register是否向此注册中心注册服务，如果设为false，将只订阅，不注册。

b)        check注册中心不存在时，是否报错。

c)        subscribe是否向此注册中心订阅服务，如果设为false，将只注册，不订阅。

d)        timeout注册中心请求超时时间(毫秒)。

e)        address可以zookeeper集群配置，地址可以多个以逗号隔开等。

  dubbo:service标签的一些属性说明：

a)        interface服务接口的路径

b)        ref引用对应的实现类的bean的id

c)        registry向指定注册中心注册，在多个注册中心时使用，值为<dubbo:registry>的id属性，多个注册中心id用逗号分隔，如果不想将该服务注册到任何registry，可将值设为n/a

d)        register 默认true ，该协议的服务是否注册到注册中心。

接下来我们启动服务提供者服务，这里我们常用的应该是启动一个java程序，因为我们的工程中并没有涉及web方面的业务，尽量不适用tomcat 启动web容器。

 

此时我们看下dubbo控制台，我们的服务已经注册进zookeeper中，服务完成。

 

7.   服务消费者

我们写一个消费者工程项目，结构如下：

 

pom文件与服务者要引用的基本一样，都是dubbo与zookeeper。

我们同样写一个接口类，与服务端的接口一致，此处如果服务端的接口分层出来，我们可以直接引用的，则不用写此步了。

 

我们写一个控制器代码，调取接口。

 

配置我们dubbo配置文件，让zookeeper给我们订阅需要的服务，此处配置接口的订阅也可使用注解形式，但对此，如果初期我们的项目用户量不是特别大，我们不想使用分布式的时候，就不好拆除dubbo了。

 

配置说明：

   dubbo:reference 的一些属性的说明：

a)        interface调用的服务接口

b)        check 启动时检查提供者是否存在，true报错，false忽略

c)        registry 从指定注册中心注册获取服务列表，在多个注册中心时使用，值为<dubbo:registry>的id属性，多个注册中心id用逗号分隔

d)        loadbalance 负载均衡策略，可选值：random,roundrobin,leastactive，分别表示：随机，轮循，最少活跃调用。此处可在zookeeper单独配置，如下：

 

再次查看我们的dubbo控制台，发现消费者已经被注册到zookeeper中。

 

消费者服务完成，我们来写个测试。

 

8.   dubbo泛化调用（扩展篇）

q:一个php工程师想调用某个java接口，他并不能按照你约定，去写一个个的接口,此时该怎么办？

a:dubbo并不是跨语言的rpc框架，但并不是不能解决这个问题,使用dubbo的泛化调用，然后利用web返回json，这样完成跨语言的调用。

总结：泛化调用，最最直接的表现就是服务消费者不需要有任何接口的实现，就能完成服务的调用。

泛化的使用比较简单，服务提供者咱们还用上面工程，不需改变。泛化调用，肯定是调用方

去实现泛化。

看下我们的配置文件，如下：

 

有两个地方需要注意一下，第一个是interface，其实该接口在消费者端并不存在，这是与往常写的不一样的地方，第二个地方需要注意的地方就是generic=”true”这样的标签，表示该接口支持泛型调用.

来看下我们怎么用程序调用，如下一个测试：

 

从spring的上下文中读到引用的接口bean,之后却把它强转为genericservice类，通用写法。然后调用genericservice的$invoke的方法。

该方法有三个参数，第一个参数是你调用远程接口的具体方法名，第二个参数是这个方法的入参的类型，最后一个参数是值。如下：

 

 

一个php程序员想要搭建一个简单的web项目，可是你却叫他依赖于spring的配置文件，他肯定不乐意，dubbo也帮你想到了，泛型调用，服务消费端可以不依赖spring的配置文件。如下：

 

小结：泛化调用可以方便用户对dubbo服务消费者端的扩展，可以方便，丰富了服务消费者的调用方式，甚至可以做变相的rest调用，这些都是可以的，不过，它的缺点也是很明显的，参数传递复杂，不方便使用。但是这种方式是不能缺失的。