[置顶] Dubbo+Zookeeper+Spring的demo--远程调用初探

一、下载并安装Zookeeper：

    下载地址：http://www.apache.org/dist/zookeeper/

    我这里下载的是3.4.6：http://www.apache.org/dist/zookeeper/zookeeper-3.4.6/zookeeper-3.4.6.tar.gz

    下载后解压缩到本地，如下图：



 

然后，进入【conf】文件夹，将文件【zoo_sample.cfg】改为【zoo.cfg】，因为Zookeeper 在启动时会找zoo.cfg这个文件作为默认配置文件。



最后，进入【bin】文件夹，双击【zkServer.cmd】文件，启动Zookeeper。



 启动后，如下图所示：



注：启动后不要关闭该窗口，然后继续第二步

二、配置dubbo-admin的管理页面

首先，下载【dubbo-admin-2.5.3.war】包，然后直接扔到tomcat的webapps目录中，如下图：



注：经测试，最好将Tomcat的【\webapps\ROOT】目录中的内容全部删除，然后将war包中的内容解压到其中，这样管理界面就成了Tomcat的默认应用，并且管理页面中的一些操作也不会发生404错误了。

 

然后，启动tomcat，访问地址：http://localhost:8080/dubbo-admin-2.5.3/ 
  用户名和密码都是：root



登陆后，点击【服务治理】-->【提供者】/【消费者】，可以从这里查看【提供者】和【消费者】信息：





注：【dubbo-admin-2.5.3/WEB-INF/dubbo.properties】文件用于指定zookpeeper地址信息，如下：







 由于我们默认就是这个地址，所以就不需要修改了。

三、创建三个本地工程，分别对应【接口】、【提供者】和【消费者】三种角色，如下：



说明：
1、【dubbo-interface】工程用于定义API接口；

2、【dubbo-provider】工程用于定义API接口实现，并在【applicationContext.xml】配置文件中向注册中心（这里是Zookeeper）中注册自己为提供者，如下：



3、【dubbo-customer】工程就是消费者，相当于我们平时调用api的客户端，他也要在在【applicationContext.xml】配置文件中向注册中心（这里是Zookeeper）中注册自己为消费者，配置内容和【dubbo-provider】差不多，但更简单，如下：



四、运行

首先运行【dubbo-provider】工程的主程序，如下：



 

运行后，可以到管理页面查看：



 

然后，运行【dubbo-customer】工程的主程序，模拟消费者进行API调用，如下：



运行结果如下：



 

至此，整个demo全部完成。

下面说说dubbo的架构构成

dubbo运行架构如下图示：



节点角色说明：

1、Provider:暴露服务的服务提供方。 Consumer: 调用远程服务的服务消费方。

2、Registry:服务注册与发现的注册中心。 Monitor: 统计服务的调用次调和调用时间的监控中心。

3、Container: 服务运行容器.

调用关系说明： 

1、服务容器负责启动，加载，运行服务提供者。 

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

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

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

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

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

Zookeeper基本原理

ZooKeeper集群由一组Server节点组成，这一组Server节点中存在一个角色为Leader的节点，其他节点都为Follower。当客户端Client连接到ZooKeeper集群，并且执行写请求时，这些请求会被发送到Leader节点上，然后Leader节点上数据变更会同步到集群中其他的Follower节点。

ZooKeeper采用一种称为Leader election的选举算法（也有称做：分布式选举算法-Paxos）的。在整个集群运行过程中，只有一个Leader，其他的都是Follower，如果ZooKeeper集群在运行过程中Leader出了问题，系统会采用该算法重新选出一个Leader，ZooKeeper用于三台以上的服务器集群之中，只要还有超过半数的服务器在线，ZooKeeper就能够正常提供服务，过半，意味着实际能够有效参与选举的节点数量是奇书个数，否者不能有效的过半。

Zookeeper逻辑图如下，



客户端可以连接到每个server，每个server的数据完全相同。
每个follower都和leader有连接，接受leader的数据更新操作。
Server记录事务日志和快照到持久存储。
大多数server可用，整体服务就可用。
Leader节点在接收到数据变更请求后，首先将变更写入本地磁盘，以作恢复之用。当所有的写请求持久化到磁盘以后，才会将变更应用到内存中。
ZooKeeper使用了一种自定义的原子消息协议，在消息层的这种原子特性，保证了整个协调系统中的节点数据或状态的一致性。Follower基于这种消息协议能够保证本地的ZooKeeper数据与Leader节点同步，然后基于本地的存储来独立地对外提供服务。
当一个Leader节点发生故障失效时，失败故障是快速响应的，消息层负责重新选择一个Leader，继续作为协调服务集群的中心，处理客户端写请求，并将ZooKeeper协调系统的数据变更同步（广播）到其他的Follower节点。