Dubbo系列之 （二）Registry注册中心-注册（1）

引导

dubbo的服务的注册与发现，需要通过第三方注册中心来协助完成，目前dubbo支持的注册中心包括 zookeeper,consul,etcd3,eureka,nacas,redis,sofa。这些注册中心的不同支持在之后的篇章进行分享。

基础铺垫

在铺垫一些基础内容之前，根据如果下几个问题来进行回答，或许能更好的阐明dubbo的实现服务的注册和发现的实现过程。

1、dubbo是在什么时机与注册中心建立连接。

2、dubbo服务注册和导出的时机在什么时候。

3、dubbo服务的订阅时机是在什么时候。

4、dubbo服务的上下线是如何通知订阅者的。

5、dubbo是如何把这些各种第三方注册中心进行整合的。

为了回答上面的五个问题，我们一起去从dubbo的源码探寻答案，这些问题和服务的注册有关，那么首先我们需要的就是去dubbo-registry这个源码模块去查询。

基础数据结构

1、dubbo 还是通过SPI技术，根据参数URL来动态选择不同的注册中心。

@SPI("dubbo")
public interface RegistryFactory {
    @Adaptive({"protocol"})
    Registry getRegistry(URL url);
}

RegistryFactory 就是产生一个注册中心的工程，它有个自适应的方法getRegistry，那么我们知道dubbo会通过javassist动态产生一个RegistryFactory$Adaptive类，并且getRegistry方法的内部实现大致是如下：

public class RegistryFactory$Adaptive implements RegistryFactory {
    @Override
    public Registry getRegistry(URL url) {
        if (url == null) throw new IllegalArgumentException("url == null");
        String extName = (url.getProtocol() == null ? "dubbo" : url.getProtocol());
        if (extName == null)
            throw new IllegalStateException("Failed to get extension (org.apache.dubbo.registry.RegistryFactory) " +
                    "name from url (" + url.toString() + ") use keys([protocol])");
        RegistryFactory extension = ExtensionLoader.getExtensionLoader(RegistryFactory.class).getExtension(extName);
        return extension.getRegistry(url);
    }
}

它通过传入的URL的protocol协议字段排判断是什么类型注册中心。例如，url的protocol的协议是zookeeper，那么就会根据SPI的ExtensionLoader.getExtensionLoader(RegistryFactory.class).getExtension（"zookeeper"）得到一个产生ZooKeeper注册中心的工厂，也就是ZookeeperRegistryFactory，而ZookeeperRegistryFactory这个类的getRegistry就是返回一个Zookeeper注册中心。

2、Registry 接口是所有注册中心的抽象。它的类关系图如下：

可以看出其语义，一个注册中心Registry是一个节点（extends Node），并且它具有注册服务(extends RegistryService)的功能。

dubbo支持如下这些注册中心zookeeper,consul,etcd3,eureka,nacas,redis,sofa，那么就会产生相应如下的Registry:

ZookeeperRegistry,ConsulRegistry,EtcdRegistry,NacosRegistry,RedisRegistry,SofaRegistry。类图如下：

所以我们知道，这些注册中心都是继承FailbackRegistry，这个FailbackRegistry其意思就是说，如果一个服务注册到当前某个注册中心注册失败后，可会在后台产生一个daemon线程，定时的把注册失败服务重新注册，并且有一定的重试限制。

在上面的类图中我们并没有发现有个名为EurekaRegistry这样的类，因为实现了另一个接口ServiceDiscovery方式，类名为EurekaServiceDiscovery来进行服务发现。这些不同的注册中心的实现方式，会在下一个章节去讨论它。

3、RegistryProtocol

dubbo的协议是通过名为org.apache.dubbo.rpc.Protocol来进行抽象的，那么注册协议也是一样的，是通过org.apache.dubbo.registry.integration.RegistryProtocol来表达的，继承org.apache.dubbo.rpc.Protocol。RegistryPrtocol是扩展点Protocol的具体实现，在https://www.cnblogs.com/liferecord/p/13445631.html文章中提到，会一次调用其setter方法来注入其需要的属性，RegistryPrtocol其中有个属性就是RegistryFactory，那么就要为它注入一个具体的RegistryFactory，那么这个具体的RegistryFactory工厂是什么类型，答案就是上面的RegistryFactory$Adaptive。为什么？因为在https://www.cnblogs.com/liferecord/p/13445631.html中提到了注入的属性对象会从SpringExtensionFactory和SpiExtensionFactory工厂中查询，刚好RegistryFactory也是一个扩展点，所以会在SpiExtensionFactory找出，并且SpiExtensionFactory工厂的实现如下：

public class SpiExtensionFactory implements ExtensionFactory {

    @Override
    public <T> T getExtension(Class<T> type, String name) {
        if (type.isInterface() && type.isAnnotationPresent(SPI.class)) {
            ExtensionLoader<T> loader = ExtensionLoader.getExtensionLoader(type);
            if (!loader.getSupportedExtensions().isEmpty()) {
                return loader.getAdaptiveExtension();
            }
        }
        return null;
    }

}

所以知道是返回一个自适应的扩展点，即RegistryFactory$Adaptive。

Protocol协议具有导出服务export()功能，和引用服务refer()功能。在RegistryProtocol中，在这个2个方法内就有对服务注册到注册中心的操作。

4、服务导出

在服务导出中，首先要有一个认知，这个认知会在后续章节中进行详细的介绍，先开始知道有这么一件事情即可，我们做dubbo服务暴露的时候，我们有2中方式，一种是通过注解的方式：

@DubboService,@Service(非spring的）。或者通过xml的方式<dubbo:service />。

不管采用哪一种方式，最终需要暴露的服务首先会包装成一个ServiceBean的对象。这个ServiceBean 持有具体需要服务注册的对象ref。ServiceBean的类图如下：

服务导出也是是一个繁琐的过程，所以在后面的章节进行详细的探讨，本章我们只要知道其服务导出引入与注册中心交互。

5、dubbo启动引导其服务导出。

DubboBootstrap是一个dubbo框架启动的帮助类，他有一个start()方法，在该方法的内部就会调用exportServices()用于导出服务，和调用referServices()进行引用服务。那么DubboBootstrap的start()方法是被谁调用？

一般使用dubbo框架的都会引入Spring框架，Spring框架有一个事件监听机制,dubbo正是监听Spring的上下文刷新事件ContextRefreshedEvent，来启动Dubbo服务的。这个服务监听类就是DubboBootstrapApplicationListener。

DubboBootstrapApplicationListener是如何注册到Spring中的呢？

1、如果是通过注解@DubboService,就是通过ServiceClassPostProcessor类，该类是实现了Spring的BeanDefinitionRegistryPostProcessor。所以通过registerBeans进行注册。在@EnableDubbo注解上有一个@DubboComponentScan注解，该注解上的@export注解就会导入DubboComponentScanRegistrar类，在该类中完成DubboBootstrapApplicationListener的注册。

2、如果是通过<dubbo:service />的方式，我们知道Spring对于自定义的标签，需要自已提供一个NamespaceHanlder的实现类来协助解析自定义标签。而dubbo的NamespaceHanlder实现类为DubboNamespaceHandler。DubboNamespaceHandler该类就有该监听器的注入。

并且classpath下的META-INF下新增spring.hanlders和spring.schemes。内容如下：

spring.shemes ：

http://dubbo.apache.org/schema/dubbo/dubbo.xsd=META-INF/dubbo.xsd

说明dubbo的命名空间文件位置

spring.handler:

http://dubbo.apache.org/schema/dubbo=org.apache.dubbo.config.spring.schema.DubboNamespaceHandler

说明处理该命名空间下的自定义标签通过DubboNamespaceHandler.

3、具体的Spring 自定义标签运用可以参考https://www.cnblogs.com/liferecord/p/7511617.html。

特征测试

在经过以上的基础铺垫之后，我们对Registry和RegistryProtocol协议进行测试。

本章主要主要的关注点在注册上，把目光移到RegistryProtocol的registry方法上。

private void register(URL registryUrl, URL registeredProviderUrl) {
        Registry registry = registryFactory.getRegistry(registryUrl);
        registry.register(registeredProviderUrl);
}

其中，

registryUrl 为注册的URL,例如：zookeeper://127.0.0.1:2181/org.apache.dubbo.registry.RegistryService?application=dubbo-demo-annotation-provider&dubbo=2.0.2&export=dubbo://192.168.0.105:20880/org.apache.dubbo.demo.DemoService?anyhost=true&application=dubbo-demo-annotation-provider&bind.ip=192.168.0.105&bind.port=20880&deprecated=false&dubbo=2.0.2&dynamic=true&generic=false&interface=org.apache.dubbo.demo.DemoService&metadata-type=remote&methods=sayHello,sayHelloAsync&pid=9990&release=&side=provider&timestamp=1596943034484&pid=9990&registry_protocol=zookeeper&timestamp=1596943034477

registeredProviderUrl 为服务提供者需要被注册的URL。例如：dubbo://192.168.0.105:20880/org.apache.dubbo.demo.DemoService?anyhost=true&application=dubbo-demo-annotation-provider&deprecated=false&dubbo=2.0.2&dynamic=true&generic=false&interface=org.apache.dubbo.demo.DemoService&metadata-type=remote&methods=sayHello,sayHelloAsync&pid=9990&release=&side=provider&timestamp=1596943034484

从上面的样例可以知道，registeredProviderUrl就是registryUrl 中参数export中的值。

test1

@Test
    public  void testRegistry(){
        // 根据SPI 获取RegistryFactory 自适应注册工厂
        RegistryFactory registryFactory = ExtensionLoader.getExtensionLoader(RegistryFactory.class).getAdaptiveExtension();

        //通过url.getProtocol 和registryFactory得到 zookeeper注册中心
        URL registryUrl=URL.valueOf("zookeeper://127.0.0.1:2181/org.apache.dubbo.registry.RegistryService?application=dubbo-demo-annotation-provider&dubbo=2.0.2&export=dubbo://192.168.0.105:20880/org.apache.dubbo.demo.DemoService?anyhost=true&application=dubbo-demo-annotation-provider&bind.ip=192.168.0.105&bind.port=20880&deprecated=false&dubbo=2.0.2&dynamic=true&generic=false&interface=org.apache.dubbo.demo.DemoService&metadata-type=remote&methods=sayHello,sayHelloAsync&pid=9990&release=&side=provider&timestamp=1596943034484&pid=9990&registry_protocol=zookeeper&timestamp=1596943034477");
        Registry zookeeperRegistry = registryFactory.getRegistry(registryUrl);

        //根据zookeeperRegistry注册中心注册，需要的服务providerRegistryURL
        URL providerRegistryURL=URL.valueOf("dubbo://192.168.0.105:20880/org.apache.dubbo.demo.DemoService?anyhost=true&application=dubbo-demo-annotation-provider&deprecated=false&dubbo=2.0.2&dynamic=true&generic=false&interface=org.apache.dubbo.demo.DemoService&metadata-type=remote&methods=sayHello,sayHelloAsync&pid=9990&release=&side=provider&timestamp=1596943034484");
        zookeeperRegistry.register(providerRegistryURL);
    }

源码跟踪

registry方法定位到FailbackRegistry，主要作用当服务注册失败后，可以在后端线程重试。

  public void register(URL url) {
        // 判断该注册中心能接受的协议
        if (!acceptable(url)) {
            logger.info("URL " + url + " will not be registered to Registry. Registry " + url + " does not accept service of this protocol type.");
            return;
        }
        // 调用AbstractRegistry的register(),主要是吧注册的URL放入registered集合中，说明该URL已经要被注册
        super.register(url);
        removeFailedRegistered(url); // 当前URL需要被注册，所以把它从注册失败列表里移除，因为可能是重试注册。
        removeFailedUnregistered(url); // 当前URL需要被注册，所以把它从注销失败列表里移除，因为可能是重试注册。
        try {
            //调用子类的具体doRegister，模板方法
            doRegister(url);
        } catch (Exception e) {
            Throwable t = e;

            // If the startup detection is opened, the Exception is thrown directly.
            // 查看是否check字段是否设置为true.
            boolean check = getUrl().getParameter(Constants.CHECK_KEY, true)
                    && url.getParameter(Constants.CHECK_KEY, true)
                    && !CONSUMER_PROTOCOL.equals(url.getProtocol());
            boolean skipFailback = t instanceof SkipFailbackWrapperException;
            //如果需要严格检测的话，直接抛异常
            if (check || skipFailback) {
                if (skipFailback) {
                    t = t.getCause();
                }
                throw new IllegalStateException("Failed to register " + url + " to registry " + getUrl().getAddress() + ", cause: " + t.getMessage(), t);
            } else {
                logger.error("Failed to register " + url + ", waiting for retry, cause: " + t.getMessage(), t);
            }

            // 否则把注册失败的URL 添加到failedRegistered，注册失败列表
            addFailedRegistered(url);
        }
    }

   private void addFailedRegistered(URL url) {
        //获取该注册URL是否已经存在在注册失败列表里，存在直接返回
        FailedRegisteredTask oldOne = failedRegistered.get(url);
        if (oldOne != null) {
            return;
        }
        // 否则创建一个失败注册重试任务FailedRegisteredTask，放入failedRegistered中。
        FailedRegisteredTask newTask = new FailedRegisteredTask(url, this);
        oldOne = failedRegistered.putIfAbsent(url, newTask);
        if (oldOne == null) {
            // 然后把该失败注册任务放入daemon线程retryTimer,定式重新注册
            retryTimer.newTimeout(newTask, retryPeriod, TimeUnit.MILLISECONDS);
        }
    }

由于章节篇幅限时，具体的doRegistry方法在后面章节分享。在下一个章节详细分析AbstractRegistry 的作用和FailbackRegistry的重试机制，并且详细剖析ZookeeperRegistry。