dubbo是阿里的一个开源soa框架，详细介绍http://code.alibabatech.com/wiki/display/dubbo/Home-zh

zookeeper是Hadoop的子项目，主要功能基于paxos算法对分布式系统的请求进行调度，详细介绍http://www.ibm.com/developerworks/cn/opensource/os-cn-zookeeper/

考虑到单机部署运行，在此文档中RegisterGroup 是单例的Zookeeper，部署集群模式的registerGroup请参考Zookeeper集群 http://wenku.baidu.com/view/641998d649649b6648d747a7.html

代码下载[不含 app的lib]http://download.csdn.net/detail/goliathray/5048969

需要的工具 eclipse tomcat

ProviderGroup：可以存在多个ProviderGroup，每个Group由多台Node组成，每个Node需要保证以下配置

1.      采用相同的application name

2.      保证provider的连接地址互不相同（在单机上部署多个provider需要保证端口不同）

3.      注册中心地址一致

 

ConsumerGroup：可以存在多个ConsumerGroup，每个Group由多台Node组成，每个Node需要保证能网络连接到所需业务的Provider并保证以下配置

1.      采用相同的application name

2.      注册中心地址一致

 

ProviderNode可以作为ConsumerNode调用别的ProviderGroup组的业务，相对的ConsumerNode也可以作为ProviderNode

 

RegisterGroup：注册中心组作为服务调用的分配者，每个RegisterNode监听除自身以外所有节点是否存活和健康（包括其RegisterGroup），本文档以Zookeeper单例部署为例子说明。

DubboAdmin：管理节点，可选节点，只作为一个管理者和观察者。

部署说明：

1.      在Eclipse中引入DubboConsumerNode1 - 3 和DubboProviderNode1 -3 共6个项目

2.      将DubboAdmin中的文件复制到apache-tomcat\webapps\ROOT下

3.      Zookeeper已经做了基础配置，只需在 \zookeeper-3.4.4\bin启动 zkServer.cmd

Zoo.cfg配置说明

#tickTime：这个时间是作为 Zookeeper 服务器之间或客户端与服务器之间维持心跳的时间间隔，也就是每个 tickTime 毫秒时间就会发送一个心跳。

tickTime=2000

#dataDir：Zookeeper 保存数据的目录，默认情况下，Zookeeper 将写数据的日志文件也保存在这个目录里。

dataDir=/tmp/zookeeper

#dataLogDir:日志文件保存的位置（未配置）

dataLogDir=/tmp/zookeeper/log

#clientPort：这个端口就是客户端连接Zookeeper 服务器的端口，Zookeeper 会监听这个端口，接受客户端的访问请求。

clientPort=2181

#initLimit：这个配置项是用来配置 Zookeeper接受客户端（这里所说的客户端不是用户连接 Zookeeper 服务器的客户端，而是 Zookeeper 服务器集群中连接到 Leader 的 Follower 服务器）初始化连接时最长能忍受多少个心跳时间间隔数。

#当已经超过 10 个心跳的时间（也就是tickTime）长度后 Zookeeper 服务器还没有收到客户端的返回信息，那么表明这个客户端连接失败。总的时间长度就是 10*2000=20 秒。

initLimit=10 

启动顺序：

这个部署并不严格要求启动的前后顺序，建议启动顺序

1.      启动Zookeeper ，显示

2.      启动Tomcat，若先启动Tomcat则会一直监听Zookeeper服务是否启动，当Zookeeper启动后才会加载完成，启动完成后访问127.0.0.1:8080，以root/root 登陆，显示

3.      启动Provider，在eclipse中找到Provider1-3.java,直接运行main方法，每启动一个节点，显示

同时在提供者列表中会增加一个节点信息

3个Provider全启动后

4.      启动Consumer, 在eclipse中找到Consumer1-3.java,直接运行main方法，每启动一个节点，可以见到console有输出

在Provider的Console中有显示

同时在消费者列表有新增节点信息

3个Consumer全启动后

 

节点的异常：

ProviderNode异常：当某台ProviderNode宕机后，Register无法再获取此Provider的信息，但是在进行initLimit个心跳连接之前，Register会认为这个Node只是暂时出错，并不会把他剔除出Provider的列表，Consumer的调用会报错（在未配置容错的情况下），某台Consumer可能会显示

但是在经过initLimit次的心跳后，此节点会被剔除出Provider列表，访问恢复

 

ConsumerNode异常：除非存在P-C-P的循环，不会对此部署产生影响，在经过initLimit次的心跳后，在Consumer列表中被剔除

RegisterNode异常：参考Zookeeper集群异常

异常恢复：对于每个ProviderNode和ConsumerNode，只需要重启动后连接上Register，既可以恢复原有的服务状态。

 

DubboAdmin管理：

DubboAdmin本身的配置采用的是文件的方式保存配置信息，配置的结果信息会由各个节点保存到临时文件，以保证在重启服务后恢复到原有状态

权重负载均衡：默认采用的是随机权重的负载均衡，对于第一次加载的Provider服务，权重为100，服务的访问率为（节点服务权重/服务重权重）*100%，可以通过增减权重的方式改变节点的访问几率，在对1号节点增加4倍权重后，1号节点的访问概率变为66.7%，可以在3个Provider节点的Console中看到信息的增幅速度明显改变，1号节点的速度远大于其他2个节点。

自定义的负载均衡：可以新增负载均衡的规则，优先于默认的负载均衡，有随机，伦循，按最小并发3种规则，可以细化到方法。

 

消费者的容错：在Provider端出现异常时，可以默认返回一个容错值，默认为Null，可以自己配置，通过对Provider的Service设置mock类

启动容错后若Provider端出错，返回Null，优先于禁用

可以看到Consumer的Console报错

消费者的禁用：对于ConsumerNode，禁用后则不能访问任何Provider

若设置了容错，则返回NULL

若无容错，则返回调用异常

恢复后显示数据可以正常访问

提供者的禁用：禁止此Provider提供服务，（对下次启动生效），在重启动这个服务后显示

服务无法被访问，在点击启用后服务恢复