无论采用那种组件作为注册中心,多多少少有数据结构的不一致的问题。所以dubbo-registry-api包也只能给一个总体的框架和流程,数据结构和实现往往需要具体问题具体分析。这块我们跟随书来学一下ZK和redis的原理。
1、Zookeeper原理概述
我们知道ZK是树状的结构的注册中心,用ZK做分布式锁也是判断叶子节点存在与否的过程。之前我们也讲过,ZK节点有好多中类型,比如持久性节点,持久性顺序节点,临时节点,临时顺序节点。
持久节点:服务注册后保证节点不会丢失,注册中心重启也会存在。
持久顺序节点:在持久节点的特性基础上增加了节点先后顺序的能力。
临时节点:服务注册后连接丢失或者session超时,注册节点会自动被移除。
临时顺序节点:在临时节点的特性基础上增加了节点先后顺序的能力。
Dubbo使用Zk做注册中心时,只会创建持久节点和临时节点两种,对创建的顺序性并没有要求。
如:
/dubbo/com.tencent.service.testService/provider是服务提供者在ZK注册中心的路劲示例,其实一种树状结构,该结构分为4层:
root(根节点,对应示例中的dubbo)
Service(接口名称,对应示例中的com.tencent.service.testService)
服务目录(对应示例中的provider,同类的还有consumers、routers、configurators)
树状结构的关系如下:
1、树的根节点是注册中心的分组,下面有多个服务接口,分组值来自用户配置的中的group属性,默认为是/dubbo
2、服务接口下包括四类目录,分别是providers、consumers、routers、configurators这个路径是持久化节点。
3、服务提供者目录(/dubbo/service/providers)下面包含的接口有多个服务url元数据信息。
4、服务消费者目录(/dubbo/service/consumers)下面包含的接口有多个消费者url元数据信息。
5、路由配置目录(/dubbo/service/routers)下面包含多个用于消费者路由策略url元数据信息,路由配置后边再说。
6、动态配置目录(/dubbo/service/configurators)下面包含多个用于服务者动态配置url元数据信息。
Dubbo框架启动的时候,会根据用户配置的服务,注册中心创建4个目录,在providers和consumers目录中分别存储服务提供方,消费方的元数据信息,主要包括ip、port、权重和应用名称等数据。
在dubbo框架进行调用时,用户可以通过服务治理平台(dubbo-admin)下发路由配置,如果在运行期间改变服务参数,则用户可以通过服务治理平台(dubbo-admin)下发动态配置,服务器端会通过订阅机制收到属性变更,并重新更新已经暴露的服务。
目录名称 | 存储值示例 |
---|---|
/dubbo/service/providers | Dubbo://192.168.21.20:20880/com.alibaba.service?key=value |
/dubbo/service/consumers | Consumser://192.168.21.21:8080/com.alibaba.service?key=value |
/dubbo/service/routers | Condition://0.0.0.0/com.alibaba.service?category=routers |
/dubbo/service/configurators | Override://0.0.0.0/com.alibaba.service?configory=configurator |
服务元数据中的所有参数都是以键值对的形式存储,以服务元数据为例:
Dubbo://192.168.21.20:20880/com.alibaba.service?category=provider&name=demo-provider&..
服务元数据中包括了两个键值对,第一个key为category,key的值为provider
Dobbo中启动注册中心的方式如下:
<beans>
//适用于一个集群有多个节点,多个ip和端口用逗号隔开
<dubbo:registry protocol=”zookeeper” address=”ip:port,ip:port” />
// 适用于多个集群有多个节点,多个ip和端口用竖线分隔
<dubbo:registry protocol=”zookeeper” address=”ip:port|ip:port” />
</beans>
祝:周一愉快!