首页 诗词 字典 板报 句子 名言 友答 励志 学校 网站地图
当前位置: 首页 > 教程频道 > 软件管理 > 软件架构设计 >

zookeeper+dubbo+dubbo治理集群的简要配置[单机]

2013-08-01 
zookeeper+dubbo+dubbo管理集群的简要配置[单机]注:zookeeper集群是myid文件是没有后缀名的。转自:http://w

zookeeper+dubbo+dubbo管理集群的简要配置[单机]
注:zookeeper集群是myid文件是没有后缀名的。
转自:
http://www.verydemo.com/demo_c353_i4119.html
http://www.verydemo.com/demo_c196_i554.html

导读:考虑到单机部署运行,在此文档中RegisterGroup 是单例的Zookeeper,部署集群模式的registerGroup请参考Zookeeper集群http://wenku.baidu.com/view/641998d649649b6648d747a7.html
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提供服务,(对下次启动生效),在重启动这个服务后显示




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



上一篇 Blueprint入门之四下一篇 使用UFT进行接口测试(Web Service、REST)
总结:权重负载均衡:默认采用的是随机权重的负载均衡,对于第一次加载的Provider服务,权重为100,服务的访问率为(节点服务权重/服务重权重)*100%,可以通过增减权重的方式改变节点的访问几率,在对1号节点增加4倍权重后,1号节点的访问概率变为66.7%,可以在3个Provider节点的Console中看到信息的增幅速度明显改变,1号节点的速度远大于其他2个节点。

热点排行