zookeeper+dubbo+dubbo管理集群的简要配置[单机] - goliathray的专栏 - 博客频道 - CSDN.NET
考虑到单机部署运行，在此文档中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提供服务，（对下次启动生效），在重启动这个服务后显示
服务无法被访问，在点击启用后服务恢复
