首先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
));
|
