首先DUBBO本质上是一款RPC框架,不可缺少的2个角色:服务提供者和服务消费者。
已经剖析了服务端暴露端口过程。本文简单说下注册中心。
1.注册中心是什么玩意
这是官网提供的图例
通过图例,可以看出消费者和提供者并不是直接通信的,中间有个第三者,就是注册中心。这种结构,可以实现消费者和提供者两者的依赖,和参数信息的集群化。所以这带来了几个问题。
-
服务注册
-
服务发现
-
服务订阅
-
服务通知
2. 服务暴露及服务注册过程
《Dubbo点滴(4)之暴露服务解析》已经剖析了dubbo协议具体打开网络端口过程。本节内容会隐去这部分内容。因为一个完整的服务暴露,主要涉及2部分内容,1)打开端口等待消费者连接;2)将服务信息登记到注册中心,以告知消费者可以连接了。
有3点需要说明:
1)首先,根据条件判断会暴露一个injvm本地服务(step 6);
InjvmProtocol协议完成,主要供同一JVM种的消费者调用,提供RPC效率。
2) 为服务暴露一个dubbo服务(step 12),一般为DubboProtocol完成
3)step 12提供的的服务,注册到注册中心(step 13-step 23)。这一步是本文的剖析重点。
3.认识注册中心
该图是DUBBO的总体结构图。重点停留在Resistry层。比较重要的是几个组件
ZookeeperRegistry :负责与zookeeper进行交互
RegistryProtocol :从注册中心获取可用服务,或者将服务注册到zookeeper,然后提供服务或者提供调用代理。
RegistryDirectory :维护着所有可用的远程Invoker或者本地的Invoker。这个类实现了NotifyListner。
NotifyListener :负责RegistryDirectory和ZookeeperRegistry的通信。
FailbackRegistry:继承自Registry,实现了失败重试机制。
4. 注册中心数据模型
流程说明:
-
服务提供者启动时
-
向/dubbo/com.foo.BarService/providers目录下写入自己的URL地址。
-
-
服务消费者启动时
-
订阅/dubbo/com.foo.BarService/providers目录下的提供者URL地址。
-
并向/dubbo/com.foo.BarService/consumers目录下写入自己的URL地址。
-
-
监控中心启动时
-
订阅/dubbo/com.foo.BarService目录下的所有提供者和消费者URL地址。
-
4.Registry 结构树
ZookeeperRegistry是常见的注册中心实现方案,由ZookeeperRegistryFactory负责构造。
AbstractRegistry这个类主要存储的是已经注册的服务接口,已经订阅的服务接口和已经收到通知的接口的URL,不能直接调用。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
public
abstract
class
AbstractRegistry
implements
Registry {
// 本地磁盘缓存,其中特殊的key值.registies记录注册中心列表,其它均为notified服务提供者列表
private
final
Properties properties =
new
Properties();
// 文件缓存定时写入
private
final
ExecutorService registryCacheExecutor = Executors.newFixedThreadPool(
1
,
new
NamedThreadFactory(
"DubboSaveRegistryCache"
,
true
));
|