Duboo的探索成果分享

引言

对Duboo之前有些耳闻，对它没有过正式的学习和探索，它是阿里巴巴SOA服务化治理方案的的核心框架，每天为上千台服务器（可能更多）提供20~50亿次的访问量支持，被阿里广泛运用在其生态系统，它是一个分布式服务的解决方案，提供高性能的RPC远程服务。

对它引起重视并决定去一探究竟，这种想法产生于大概两三个月前的一次部门会议，记得当时部门领导提到一些问题，具体内容记得不是很详细了，但大致的意思是这样：

“现在公司服务模块越来越多，这些服务模块之间的依赖关系也变得越来越错综复杂，这些模块之间的调用量也越来越大，仅仅是几个平台网站就依赖了很多其他服务模块，而且配置了大量URL，现在仅仅是运维网站就配置了多个数据库连接池，比较理想的解决方案就是把核心业务抽取出来，提供一套RPC服务，解决以上的问题”。

记得随后部门里有两个同事对目前行业内RPC相关框架做了一些预研，其中一个同事用Duboo+Zookeeper弄出了一个demo，经过讨论后，我决定去研究一下Duboo，看看这个东西怎么玩起来，如何跟当前掌握的技术结合起来解决一些问题。

在之后对其探索和学习的时间里，查找了大量的资料，并且跟现在工作在大型互联网企业的一些老同事和朋友请教，讨论。最终弄出了一个基于Duboo+Zookeeper+Spring+Maven，提供RPC服务的应用。

本文将对Duboo，Zookeeper,Spring在以上组合中扮演的角色，发挥的作用做相应的介绍，并且对搭建Duboo+Zookeeper+Spring+Maven平台做一些演示和介绍。

一、要解决的问题

1. 当前我们大多数服务是通过配置服务的URl进行调用，通过多台机器配置负载均衡，单个节点的压力变大。

2. 随着企业不断发展，业务规模不断扩大，服务模块之间的依赖关系也变得越来越复杂，A依赖B才能正常运行，B依赖于C才能正常运行，如果这三个服务都是停止状态，我们需要先启动C，再启动B,然后A服务才能正常运行，这个例子仅仅是三个服务模块，现实情况会比这个多，依赖关系可能就更复杂了，那么就需要架构师画一张图，把依赖关系画清楚，然后攻城狮们才能维护好这些服务。

3. 客户越来越多，对服务的调用量越来越大，服务的性能就面临着考验了，需要多少台机器来支持，什么时候需要升级硬件配置，或者需要加机器。

二、解决问题的途径

1. 解决上面第一个问题：我们弄一个“婚姻介绍所”，单身单女都去登记，选择中意的配偶，然后约会，该比喻我认为比较形象，其实在本位所讲的技术体系中，它是一个服务注册中心，动态的注册服务和发现服务，使服务的位置变得透明，消费者按需选择生产者提供的服务，也就是他们的注册地址，从而实现软负载。

2. 第二个问题：架构师天天日理万机，难道让他去画图？增加了模块，调整了调用方式，他再去改图？如果能有个东西自动画出“婚姻介绍所”这些男女的配对关系该多好啊，那么架构师只等着收他们成功牵手后的报答费就行了。

3. 第三个问题：我们现在有个系统能对一些模块的调用量统计出来，作为数据参考，那么我们只需要能够动态调整权重就行了，如果随着某个机器的权重不断加大，相应时间接近临界值，此时的访问量乘以机器总数就是我们当前能支持的最大容量，那么什么时候该加机器也就心理有数了。

4. 由此，请出了本文所要讲的重点，一个Duboo+Zookeeper+Spring+Maven结合的RPC框架呼之欲出，接下来将对其做出讲解。

三、Duboo简介

Dubbo是一个分布式服务框架,可以解决上面提到的问题，Dubbo的架构如图所示（简单画了画，画的不好不要笑）：

各节点角色说明：

Provider: 服务提供方。

Consumer: 调用远程服务的消费方。

Registry: 注册和发现服务的一个所，在这里叫注册中心。

Monitor: 统计服务的调用次数和调用时间的监控中心。（作用于上述第三个问题）

Container: 提供给服务运行的容器（约会地点）。

调用关系说明（约会方式，和谁牵手就看他们个人爱好了）：

1. 容器启动，加载，服务提供者开始运行（婚姻介绍所开门了，男女一方开始去踩点）。

2. 服务提供者启动时，向注册中心注册自己提供的服务。（注册并登记，在所里登记自己的特长，爱好，留个手机号码之类的）

3. 服务消费者启动时，向注册中心订阅自己所需的服务。（另一方也来所里了，开始看花名册选中意的对象）

4. 注册中心返回服务提供者地址列表给消费者，如果服务提供者有变更，注册中心将基于长连接推送变更数据给消费者。（其中一方电话号码变了，所里红娘要告诉另一方新的电话号码，否则双方就失联了）

5. 服务消费者，基于软负载均衡算法，从提供者地址列表中，选一台提供者进行调用，如果调用失败，再选另一台调用。（先选一个中意对象，如果这个伴侣看不上自己，或者跑了，就再选一个）

6. 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。（要反馈给所里相处的情况，看了几次电影，吃了几次饭，有没有超过嘴，所里要评估一下，牵手成功的概率有多大）

Duboo还支持很多协议，Duboo协议，RMI协议，Hessian协议。（可以线上选伴侣，也可以线下）

介绍到这里，大家应该对Duboo具体干的事情有了一个概念，有了这个概念，在整合使用它时，思路就清晰多了，说到这，是不是感觉我提到的“婚姻介绍所”的比喻是不是越来越形象了？

简单的事物它其实蛮复杂，复杂的事情其实它又蛮简单。

四、Zookeeper在此是干什么的

Dubbo支持多种类型的注册中心，Multicast注册中心，Zookeeper注册中心，Redis注册中心，Simple注册中心，在这里我们选择Zookper是作为Duboo的注册中心来使用的。

为什么选择Zookeeper呢？

Zookeeper一个分布式的服务框架, 为服务提供树型的目录数据存储结构，可以做到集群方式管理数据，在这里作为Duboo的注册中心，能做到Duboo+Zookper集群方式部署（别告诉我以后没计划或者不可能去使用集群），如果其中一个服务提供者down了，他可以自动删除这个服务提供者信息，如果这个服务又重启了，他可以自动恢复注册的信息，继续处理订阅的请求。

五、Spring用来干什么

我们弄这个RPC框架是用来提供服务的，提供服务当然很容易想到使用Spring了，开发过服务端接口的同学应该很清楚它的优势吧，至今一定仍然心有余悸，其提供的各种便捷，方便集成各种优秀框架，那叫一个酣畅淋漓，就不用我在这里再多啰嗦了吧。

Maven就不说吧，帮我们管理项目的。

在下面的章节中演示一下该RPC框架构建过程，再次演示的是单机模式，集群模式由于资源的限制，再次就不做演示了。

六、动手去干

1.先搞定Zookeeper

下载地址：http://www.apache.org/dyn/closer.cgi/zookeeper/，下载下来后直接解压。

修改其配置项, Zookeeper在启动时会找一个叫zoo.cfg的配置文件，配置文件在 conf 目录下，把zoo_sample.cfg改名为zoo.cfg。

这个文件里还有其他几个重要的配置项：

tickTime：客户端与服务器之间维持心跳的时间间隔。

clientPort：Zookeeper的监听端口，接受客户端的请求。

好了，进入其bin目录，通过zkServer.sh 或者zkServer.cmd启动注册中心，zookeeper2181端口。

2.把服务提供者搞出来

2.1加入Zookeeper的依赖包

2.2写一个服务接口，定义一个方法：

2.3写实现类，并实现其定义的方法：

2.4在Spring配置文件中把服务交给容器管理。

3.把消费者搞出来

再创建一个工程，在此工程模拟消费者

配置要引用的地址：

dubbo:reference有个属性，loadbalance：负载均衡策略，可选值：random,roundrobin,leastactive，分别表示：随机，轮循，最少活跃调用。

然后我们弄个ajax程序或者直接拼个URL请求一下这个消费者，让他运行一下。

4.去观察一下是否牵手成功

下载dubbo的war包，部署到tomcat下，启动tomcat，访问，输入用户名，密码（在WEB-INF下dubbo.properties中，默认是root/guest）

由于我的注册中心在101机器上，服务提供者和消费者都在102机器上（由于没那么多电脑可以使用，提供服务端和消费都弄在了一台机器上）。

访问Tomcat，http://192.168.1.101:8080/dubooAdmin

生产者：

消费者：