ZookeeperRegistryFactory

Zookeeper注册中心安装

建议使用dubbo-2.3.3以上版本的zookeeper注册中心客户端。Zookeeper是Apache Hadoop的子项目，强度相对较好，建议生产环境使用该注册中心。Dubbo未对Zookeeper服务器端做任何侵入修改，只需安装原生的Zookeeper服务器即可，所有注册中心逻辑适配都在调用Zookeeper客户端时完成。如果需要，可以考虑使用taobao的zookeeper监控：http://rdc.taobao.com/team/jm/archives/1450

安装:

wget http://www.apache.org/dist//zookeeper/zookeeper-3.3.3/zookeeper-3.3.3.tar.gz

tar zxvf zookeeper-3.3.3.tar.gz

cd zookeeper-3.3.3

cp conf/zoo_sample.cfg conf/zoo.cfg

配置:

vi conf/zoo.cfg

如果不需要集群，zoo.cfg的内容如下：(其中data目录需改成你真实输出目录)

tickTime=2000 initLimit=10 syncLimit=5 dataDir=/home/dubbo/zookeeper-3.3.3/data clientPort=2181

如果需要集群，zoo.cfg的内容如下：(其中data目录和server地址需改成你真实部署机器的信息)

tickTime=2000 initLimit=10 syncLimit=5 dataDir=/home/dubbo/zookeeper-3.3.3/data clientPort=2181 server.1=10.20.153.10:2555:3555 server.2=10.20.153.11:2555:3555

并在data目录下放置myid文件：(上面zoo.cfg中的dataDir)

mkdir data vi myid

myid指明自己的id，对应上面zoo.cfg中server.后的数字，第一台的内容为1，第二台的内容为2，内容如下：

1

启动:

./bin/zkServer.sh start

停止:

./bin/zkServer.sh stop

命令行: (See:  http://zookeeper.apache.org/doc/r3.3.3/zookeeperAdmin.html )

telnet 127.0.0.1 2181
dump

或者

echo dump | nc 127.0.0.1 2181

用法：

dubbo.registry.address=zookeeper://10.20.153.10:2181?backup=10.20.153.11:2181

或者

<dubbo:registryprotocol="zookeeper"address="10.20.153.10:2181,10.20.153.11:2181"/>

管理控制台安装

管理控制台为内部裁剪版本，开源部分主要包含：路由规则，动态配置，服务降级，访问控制，权重调整，负载均衡，等管理功能。

安装:

wget http://apache.etoak.com/tomcat/tomcat-6/v6.0.35/bin/apache-tomcat-6.0.35.tar.gz tar zxvf apache-tomcat-6.0.35.tar.gz cd apache-tomcat-6.0.35 rm -rf webapps/ROOT

wget http://code.alibabatech.com/mvn/releases/com/alibaba/dubbo-admin/2.4.1/dubbo-admin-2.4.1.war

unzip dubbo-admin-2.4.1.war -d webapps/ROOT

配置: (或将dubbo.properties放在当前用户目录下)

vi webapps/ROOT/WEB-INF/dubbo.properties

dubbo.registry.address=zookeeper://127.0.0.1:2181 dubbo.admin.root.password=root dubbo.admin.guest.password=guest

启动:

./bin/startup.sh

停止:

./bin/shutdown.sh

访问: (用户:root,密码:root 或 用户:guest,密码:guest)

http://127.0.0.1:8080/

 

注册中心抽象

Dubbo的将注册中心进行抽象，是得它可以外接不同的存储媒介给注册中心提供服务，有ZooKeeper，Memcached，Redis等。Dubbo抽象后，用户可以进行扩展，我们通过分析ZooKeeper这个实现来了解注册中心的低层。进过抽象之后，用户 只需要实现对应的Registry和RegistryFactory就可以了，ZooKeeper就是实现了ZookeeperRegistry，和ZookeeperRegistryFactory。

ZookeeperRegistryFactory的实现很简单，就是返回一个ZookeeperRegistry实例，所以主要的东西是在ZookeeperRegistry中实现的，在ZookeeperRegistry用户需要实现注册URL，注销URL，URL订阅，URL注销订阅和URL查询，在这里面设计到Zookeeper服务端的调用，都被封装到ZookeeperClient中，ZookeeperClient服务进行Server连接，断链；资源的CRUD。

ZooKeeper的价值

由于引入了ZooKeeper作为存储媒介，也就把ZooKeeper的特性引进来。首先是负载均衡，单注册中心的承载能力是有限的，在流量达到一定程度的时候就需要分流，负载均衡就是为了分流而存在的，一个ZooKeeper群配合相应的Web应用就可以很容易达到负载均衡；资源同步，单单有负载均衡还不够，节点之间的数据和资源需要同步，ZooKeeper集群就天然具备有这样的功能；命名服务，将树状结构用于维护全局的服务地址列表，服务提供者在启动的时候，向ZK上的指定节点/dubbo/${serviceName}/providers目录下写入自己的URL地址，这个操作就完成了服务的发布。其他特性还有Mast选举，分布式锁等。

alibaba有好几个分布式框架，主要有：进行远程调用(类似于RMI的这种远程调用)的(dubbo、hsf)，jms消息服务(napoli、notify)，KV数据库(tair)等。 这个框架/工具/产品在实现的时候，都考虑到了容灾，扩展，负载均衡，于是出现一个配置中心(ConfigServer)的东西来解决这些问题。

基本原理如图：

 

在我们的系统中，经常会有一些跨系统的调用，如在A系统中要调用B系统的一个服务，我们可能会使用RMI直接来进行，B系统发布一个RMI接口服务，然后A系统就来通过RMI调用这个接口，为了解决容灾，扩展，负载均衡的问题，我们可能会想很多办法，alibaba的这个办法感觉不错。

本文只说dubbo， 原理如下：

• ConfigServer

配置中心， 和每个Server/Client之间会作一个实时的心跳检测（ 因为它们都是 建立的Socket长连接 ） ，比如几秒钟检测一次。 收集每个Server提供的服务的信息，每个Client的信息，整理出一个服务列表，如：

serviceName	serverAddressList	clientAddressList
UserService	192.168.0.1，192.168.0.2，192.168.0.3，192.168.0.4	172.16.0.1，172.16.0.2
ProductService	192.168.0.3，192.168.0.4，192.168.0.5，192.168.0.6	172.16.0.2，172.16.0.3
OrderService	192.168.0.10，192.168.0.12，192.168.0.5，192.168.0.6	172.16.0.3，172.16.0.4

当某个 Server不可用，那么就 更新受影响的服务对应的 serverAddressList，即把这个Server从serverAddressList中踢出去 （从地址列表中删除） ，同时将 推送 serverAddressList 给这些受影响的服务的 clientAddressList里面的所有Client 。如：192.168.0.3挂了，那么UserService和ProductService的serverAddressList都要把192.168.0.3删除掉，同时把新的列表告诉对应的Client  172.16.0.1，172.16.0.2， 172.16.0.3 ；

当 某 个Client挂了，那么 更新受影响的服务对应的clientAddressList

ConfigServer根据服务列表，就能提供一个web管理界面，来查看管理服务的提供者和使用者。

新加一个Server时，由于它会主动与ConfigServer取得联系，而ConfigServer又会将这个信息主动发送给Client，所以 新加一个Server时，只需要启动Server，然后几秒钟内，Client就会使用上它提供的服务

• Client

调用服务的机器，每个Client启动时，主动与ConfigServer建立Socket长连接，并将自己的IP等相应信息发送给ConfigServer。

Client在使用服务的时候根据服务名称去ConfigServer中获取服务提供者信息（这样ConfigServer就知道某个服务是 当前 哪几个Client在使用），Client拿到这些服务提供者信息后，与它们都建立连接，后面就可以直接调用服务了，当有多个服务提供者的时候，Client根据一定的规则来进行负载均衡，如轮询，随机，按权重等。

一旦Client使用的服务它对应的服务提供者有变化（服务提供者有新增，删除的情况），ConfigServer就会把最新的服务提供者列表推送给Client，Client就会依据最新的服务提供者列表重新建立连接，新增的提供者建立连接，删除的提供者丢弃连接

• Server

真正提供服务的机器，每个Server启动 时 ，主动与ConfigServer建立Scoket长连接，并将自己的IP，提供的服务名称，端口等信息直接发送给ConfigServer，ConfigServer就会收集到每个Server提供的服务的信息。

优点：

1，只要在Client和Server启动的时候，ConfigServer是好的，服务就可调用了，如果后面 ConfigServer挂了，那只影响 ConfigServer挂了以后服务提供者有变化，而Client还无法感知这一变化。

2，Client每次调用服务是不经过ConfigServer的，Client只是与它建立联系，从它那里获取提供服务者列表而已

3，调用服务- 负载均衡： Client调用服务时，可以根据规则在多个服务提供者之间轮流调用服务。

4， 服务提供者- 容灾：某一个Server挂了，Client依然是可以正确的调用服务的，当前提是这个服务有至少2个服务提供者，Client能很快的感知到服务提供者的变化，并作出相应反应。

5，服务提供者-扩展：添加一个服务提供者很容易，而且Client会很快的感知到它的存在并使用它。