上篇文章如果有人问你 Dubbo 中注册中心工作原理&＃xff0c;就把这篇文章给他大致了解了注册中心作用以及 Dubbo Registry 模块源码&＃xff0c;这篇文章将深入 Dubbo ZooKeeper 模块&＃xff0c;去了解如何实现服务动态的发现。
ps: 以下将 ZooKeeper 缩写为 zk。
在 ZooKeeper 基本概念分享一文讲道&＃xff0c;ZK 内部是一种树形层次结构&＃xff0c;节点存在多种类型。而 Dubbo 只会创建持久节点和临时节点。
若服务提供者服务接口为 com.service.FooService&＃xff0c;将会在 ZK 中创建创建如下路径 /dubbo/com.service.FooService/providers/providerURL。
服务路径分为四层&＃xff0c;根节点默认为 dubbo&＃xff0c;可以在 dubbo-registry 设置 group 属性改变该值。
ps: 若无注册中心隔离需求&＃xff0c;不要随便修改。
第二层节点为服务节点全名称&＃xff0c;如 com.service.FooService。
第三层节点为服务目录&＃xff0c;如 providers。另外还存在其他目录节点&＃xff0c;分别为 consumers&＃xff08;消费者目录&＃xff09;&＃xff0c;configurators&＃xff08;配置目录&＃xff09;&＃xff0c;routers&＃xff08;路由目录&＃xff09;。下面服务订阅主要针对这一层节点。
第四个节点为具体服务节点&＃xff0c;节点名为具体的 URL 字符串&＃xff0c;如 dubbo://2.0.1.13:12345/com.dubbo.example.DemoService?xx&＃61;xx &＃xff0c;该节点默认为临时节点。 dubbo ZK 树形内部结构示例为&＃xff1a;
ZK 内部服务具体示例如下&＃xff1a;
Dubbo 可以在配置文件中指定使用注册中心&＃xff0c;可以使用 dubbo.registry.protocol 指定具体注册中心类型&＃xff0c;也可以设置 dubbo.registry.address 指定。注册中心相关实现将会使用 RegistryFactory 工厂类创建。
RegistryFactory 接口源码如下:
&＃64;SPI("dubbo")
public interface RegistryFactory {&＃64;Adaptive({"protocol"})Registry getRegistry(URL url);
}
RegistryFactory 接口方法使用 &＃64;Adaptive 注解&＃xff0c;这里将会使用 Dubbo SPI 机制&＃xff0c;自动生成代码的一些实现逻辑。这里将会根据 URL 中 protocol 属性&＃xff0c;去调用最终实现子类。
RegistryFactory 实现子类如图所示&＃xff1a;
AbstractRegistryFactory 将会实现接口的 getRegistry 方法&＃xff0c;主要完成加锁&＃xff0c;并调用抽象模板方法 createRegistry 创建具体注册中心实现类&＃xff0c;并将其缓存在内存中。
AbstractRegistryFactory#getRegistry 源码如下所示&＃xff1a;
public Registry getRegistry(URL url) {url &＃61; URLBuilder.from(url).setPath(RegistryService.class.getName()).addParameter(Constants.INTERFACE_KEY, RegistryService.class.getName()).removeParameters(Constants.EXPORT_KEY, Constants.REFER_KEY).build();String key &＃61; url.toServiceStringWithoutResolving();// 加锁&＃xff0c;防止并发LOCK.lock();try {// 先从缓存中取Registry registry &＃61; REGISTRIES.get(key);if (registry !&＃61; null) {return registry;}//使用 Dubbo SPI 进制创建registry &＃61; createRegistry(url);if (registry &＃61;&＃61; null) {throw new IllegalStateException("Can not create registry " &＃43; url);}// 放入缓存REGISTRIES.put(key, registry);return registry;} finally {// Release the lockLOCK.unlock();}}
注册中心实例将会通过具体工厂类创建&＃xff0c;这里我们看下 ZookeeperRegistryFactory 源码&＃xff1a;
public class ZookeeperRegistryFactory extends AbstractRegistryFactory {private ZookeeperTransporter zookeeperTransporter;/*** 通过 Dubbo SPI 进制注入* &＃64;param zookeeperTransporter*/public void setZookeeperTransporter(ZookeeperTransporter zookeeperTransporter) {this.zookeeperTransporter &＃61; zookeeperTransporter;}&＃64;Overridepublic Registry createRegistry(URL url) {return new ZookeeperRegistry(url, zookeeperTransporter);}}
ps&＃xff1a;Dubbo SPI 机制还具有 IOC 特性&＃xff0c;这里的ZookeeperTransporter 注入可以参考&＃xff1a;Dubbo 扩展点加载
讲完注册中心实例创建过程&＃xff0c;下面深入 ZookeeperRegistry 实现源码。
ZookeeperRegistry 继承 FailbackRegistry抽象类&＃xff0c;所以其需要实现其父类抽象模板方法&＃xff0c;下面主要了解 doRegister 与 doSubscribe源码 。
服务提供者需要将服务注册到注册中心&＃xff0c;注册的目的是为了让消费者感知到服务的存在&＃xff0c;从而发起远程调用&＃xff0c;另一方面也让服务治理中心感知新的服务提供者上线。zk 模块服务注册代码比较简单&＃xff0c;直接使用 zk 客户端在注册中心创建节点。
ZookeeperRegistry#doRegister 实现源码如下&＃xff1a;
public void doRegister(URL url) {try {zkClient.create(toUrlPath(url), url.getParameter(Constants.DYNAMIC_KEY, true));} catch (Throwable e) {throw new RpcException("Failed to register " &＃43; url &＃43; " to zookeeper " &＃43; getUrl() &＃43; ", cause: " &＃43; e.getMessage(), e);}}
zkClient.create 方法需要传入两个参数。
void create(String path, boolean ephemeral);
第一个参数为节点路径&＃xff0c;将会通过 toUrlPath 将 URL 实例转化成 ZK 中路径格式&＃xff0c;转化结果如下&＃xff1a;
## 转化前 URL 如下&＃xff1a;dubbo://10.20.82.31:12345/com.dubbo.example.DemoService## 调用 &＃96;toUrlPath&＃96; 转换之后
/dubbo/com.dubbo.example.DemoService/providers/dubbo%3A%2F%2F10.20.82.31%3A12345%2Fcom.dubbo.example.DemoService
第二个参数主要决定 ZK 节点类型主要取自 URL 实例对象中 dynamic 参数值&＃xff0c;若不存在&＃xff0c;默认为 true&＃xff0c;也就是默认将会创建临时节点。
zkClient.create 方法里将会递归调用&＃xff0c;首先父节点是否存在&＃xff0c;不存在就会创建&＃xff0c;直到最后一个节点跳出递归方法。
public void create(String path, boolean ephemeral) {// 创建永久节点之前需要判断是否已存在if (!ephemeral) {if (checkExists(path)) {return;}}// 判断是否存在父节点int i &＃61; path.lastIndexOf(&＃39;/&＃39;);if (i > 0) {// 递归创建父节点create(path.substring(0, i), false);}if (ephemeral) {// 创建临时节点createEphemeral(path);} else {// 创建永久节点createPersistent(path);}}
最后 createEphemeral 与 createPersistent 实际创建节点操作将会交给 ZK 客户端类&＃xff0c;这里实现比较简单&＃xff0c;可以自行参考源码。
ps: dubbo 在 2.6.1 起将 zk 客户端默认使用 Curator&＃xff0c;之前版本使用 zkclient。dubbo 2.7.1 开始去除 zkclient 实现&＃xff0c;也就是说只能使用 Curator 。
zk 临时节点将会在 zk 客户端断开后&＃xff0c;自动删除。dubbo 服务提供者正常下线&＃xff0c;其会主动删除 zk 服务节点。
如果服务异常宕机&＃xff0c;zk 服务节点就不能正常删除&＃xff0c;这就导致失效的服务一直存在 ZK 上&＃xff0c;消费者还会调用该失效节点&＃xff0c;导致消费者报错。通过 zk 临时节点特性&＃xff0c;让 zk 服务端主动删除失效节点&＃xff0c;从而下线失效服务。
服务订阅通常有 pull 和 push 两种方式。pull 模式需要客户端定时向注册中心拉取配置&＃xff0c;而 push 模式采用注册中心主动推送数据给客户端。
dubbo zk 注册中心采用是事件通知与客户端拉取方式。服务第一次订阅的时候将会拉取对应目录下全量数据&＃xff0c;然后在订阅的节点注册一个 watcher。一旦目录节点下发生任何数据变化&＃xff0c;zk 将会通过 watcher 通知客户端。客户端接到通知&＃xff0c;将会重新拉取该目录下全量数据&＃xff0c;并重新注册 watcher。利用这个模式&＃xff0c;dubbo 服务就可以就做到服务的动态发现。
讲完订阅的基本原理&＃xff0c;接着深入源码。
doSubscribe 方法需要传入两个参数&＃xff0c;一个为 URL 实例&＃xff0c;另一个为 NotifyListener&＃xff0c;变更事件的监听器。 方法内部会根据 URL 接口类型分成两部分逻辑&＃xff0c;全量订阅服务与部分类别订阅服务。
doSubscribe 方法整体源码逻辑&＃xff1a;
public void doSubscribe(final URL url, final NotifyListener listener) {if (Constants.ANY_VALUE.equals(url.getServiceInterface())) {// 全量订阅逻辑} else {// 部分类别订阅逻辑}}
服务治理中心(dubbo-admin)&＃xff0c;需要订阅 service 全量接口&＃xff0c;用以感知每个服务的状态&＃xff0c;所以订阅之前将会把 service 设置成 *&＃xff0c;处理所有service。
服务消费者或服务提供者将会走部分类别订阅服务&＃xff0c;下面我们以消费者视角&＃xff0c;深入后续源码。
文章刚开头讲道了 zk 目录节点存在四种类型&＃xff0c;这里将会根据 根据 URL 中 category值&＃xff0c;决定订阅节点路径。
服务提供者 URL 中 category值默认为 configurators&＃xff0c;而消费者 URL 中category值默认为 providers,configurators,routers。如果 category类别值为 *&＃xff0c;将会订阅四种类别路径&＃xff0c;否则将会只订阅 providers类型的路径。
toCategoriesPath 源码如下&＃xff1a;
private String[] toCategoriesPath(URL url) {String[] categories;// 如果类别为 *&＃xff0c;订阅四种类型的全量数据if (Constants.ANY_VALUE.equals(url.getParameter(Constants.CATEGORY_KEY))) {categories &＃61; new String[]{Constants.PROVIDERS_CATEGORY, Constants.CONSUMERS_CATEGORY,Constants.ROUTERS_CATEGORY, Constants.CONFIGURATORS_CATEGORY};} else {categories &＃61; url.getParameter(Constants.CATEGORY_KEY, new String[]{Constants.DEFAULT_CATEGORY});}// 返回路径数组String[] paths &＃61; new String[categories.length];for (int i &＃61; 0; i
接着循环路径数组&＃xff0c;循环内将会缓存节点监听器&＃xff0c;用以提高性能。
// 循环路径数组for (String path : toCategoriesPath(url)) {ConcurrentMap
最终将会使用 CuratorClient.getChildren().usingWatcher(listener).forPath(path) 在 ZK 节点注册 watcher&＃xff0c;并获取目录节点下所有子节点数据。
这里 watcher 使用 Curator 接口 CuratorWatcher&＃xff0c;一旦 ZK 节点发生会变化&＃xff0c;将会回调 CuratorWatcher#process 方法。
CuratorWatcher#process 方法源码如下&＃xff1a;
public void process(WatchedEvent event) throws Exception {if (childListener !&＃61; null) {String path &＃61; event.getPath() &＃61;&＃61; null ? "" : event.getPath();childListener.childChanged(path,// 重新设置 watcher&＃xff0c;并获取节点下所有子节点StringUtils.isNotEmpty(path)? client.getChildren().usingWatcher(this).forPath(path): Collections.
消费者订阅时序图如下&＃xff1a;
订阅方法中我们碰到了多个 listener类&＃xff0c;刚开始理解时候可能有点乱。可以参考下面关系图理清楚这其中的关系。
listener 关系图如下&＃xff1a;
回调关系如图所示&＃xff1a;
ZK 第一次订阅将会获得目录节点下所有子节点&＃xff0c;后续任意子节点变更&＃xff0c;将会通过 watcher 进制回调通知。回调通知将会再次全量拉取节点目录下所有子节点。这样全量拉取将会有个局限&＃xff0c;当服务节点较多时将会对网络造成很大的压力。
Dubbo 2.7 之后版本引入元数据中心解决该问题&＃xff0c;详情可参考&＃xff0c;阿里技术专家详解 Dubbo 实践&＃xff0c;演进及未来规划。
引用文中一种解决方案如下图:
本文主要介绍了 dubbo zk 的数据结构&＃xff0c;其次深入研究 ZookeeperRegistry 相关实现源码。通过了解服务注册以及订阅原理&＃xff0c;了解 Dubbo 服务动态发现实现方式。
京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有