最近一段时间疫情隔离在家，学习了一下Dubbo高级特性。研究了一下Dubbo源码，现在和大家一起分享一下。有什么理解不到位的地方欢迎一起指导交流！

源码构建环境 2.7.3

SPI机制

在 Dubbo 中，SPI 是一个非常重要的模块。基于 SPI，我们可以很容易的对 Dubbo 进行拓展。如果大家想要学习 Dubbo 的源码，SPI 机制务必弄懂。接下来，我们先来了解一下 Java SPI 与 Dubbo SPI 的用法，然后再来分析 Dubbo SPI 的源码。

SPI的概述

SPI的主要作用

SPI 全称为 Service Provider Interface，是一种服务发现机制。SPI 的本质是将接口实现类的全限定名配置在文件中，并由服务加载器读取配置文件，加载实现类。这样可以在运行时，动态为接口替换实现类。正因此特性，我们可以很容易的通过 SPI 机制为我们的程序提供拓展功能。

在面向的对象的设计里，不同模块之间推崇面向接口编程，不建议在模块中对实现类进行硬编码。一旦代码里涉及具体的实现类，就违反了可拔插的原则，如果需要替换一种实现，就需要修改代码。SPI使得程序能在ClassPath路径下的META-INF/services文件夹查找接口的实现类，自动加载文件里所定义的实现类。

场景：

数据库驱动java.sql.Driver，Mysql，Oracle都有自己的驱动实现jar包，只需引入不同的jar包即可加载不同的数据库驱动，例如mysql-connector-java中，其META-INF/services下制定了mysql驱动的实现类

Java SPI 实际上是“基于接口的编程＋策略模式＋配置文件”组合实现的动态加载机制。

入门案例

首先，我们定义一个接口，名称为 Robot。

public interface Robot {
    void sayHello();
}

接下来定义两个实现类，分别为 OptimusPrime 和 Bumblebee。

public class OptimusPrime implements Robot {
    
    @Override
    public void sayHello() {
        System.out.println("Hello, I am Optimus Prime.");
    }
}


public class Bumblebee implements Robot {


    @Override
    public void sayHello() {
        System.out.println("Hello, I am Bumblebee.");
    }
}

接下来 META-INF/services 文件夹下创建一个文件，名称为 Robot 的全限定名 com.itheima.java.spi.Robot。文件内容为实现类的全限定的类名，如下：

com.itheima.java.spi.impl.Bumblebee
com.itheima.java.spi.impl.OptimusPrime

做好所需的准备工作，接下来编写代码进行测试。

public class JavaSPITest {


    @Test
    public void sayHello() throws Exception {
        ServiceLoader<Robot> serviceLoader = ServiceLoader.load(Robot.class);
        System.out.println("Java SPI");
        serviceLoader.forEach(Robot::sayHello);
    }
}

最后来看一下测试结果，如下：

从测试结果可以看出，我们的两个实现类被成功的加载，并输出了相应的内容。

总结

调用过程

应用程序调用ServiceLoader.load方法，创建一个新的ServiceLoader，并实例化该类中的成员变量
应用程序通过迭代器接口获取对象实例，ServiceLoader先判断成员变量providers对象中(LinkedHashMap<String,S>类型)是否有缓存实例对象，如果有缓存，直接返回。如果没有缓存，执行类的装载，

优点

使用 Java SPI 机制的优势是实现解耦，使得接口的定义与具体业务实现分离，而不是耦合在一起。应用进程可以根据实际业务情况启用或替换具体组件。

缺点

不能按需加载。虽然 ServiceLoader 做了延迟载入，但是基本只能通过遍历全部获取，也就是接口的实现类得全部载入并实例化一遍。如果你并不想用某些实现类，或者某些类实例化很耗时，它也被载入并实例化了，这就造成了浪费。
获取某个实现类的方式不够灵活，只能通过 Iterator 形式获取，不能根据某个参数来获取对应的实现类。
多个并发多线程使用 ServiceLoader 类的实例是不安全的。
加载不到实现类时抛出并不是真正原因的异常，错误很难定位。

Dubbo中的SPI

概述

Dubbo 并未使用 Java SPI，而是重新实现了一套功能更强的 SPI 机制。Dubbo SPI 的相关逻辑被封装在了 ExtensionLoader 类中，通过 ExtensionLoader，我们可以加载指定的实现类。

入门案例

与 Java SPI 实现类配置不同，Dubbo SPI 是通过键值对的方式进行配置，这样我们可以按需加载指定的实现类。下面来演示 Dubbo SPI 的用法：

1、在使用Dubbo SPI 时，需要在接口上标注 @SPI 注解。

@SPI
public interface Robot {
    void sayHello();
}

2、Dubbo SPI 所需的配置文件需放置在 META-INF/dubbo 路径下，与 Java SPI 实现类配置不同，Dubbo SPI 是通过键值对的方式进行配置（key自己指定，value为实现类的全路径），配置内容如下。

注意：每一对key=value，我们把它称之为dubbo的扩展点

optimusPrime = org.apache.spi.OptimusPrime
bumblebee = org.apache.spi.Bumblebee

3、通过 ExtensionLoader，我们可以加载指定的实现类，下面来演示 Dubbo SPI ：

public class DubboSPITest {


    @Test
    public void sayHello() throws Exception {
        ExtensionLoader<Robot> extensionLoader = 
            ExtensionLoader.getExtensionLoader(Robot.class);
        Robot optimusPrime = extensionLoader.getExtension("optimusPrime");
        optimusPrime.sayHello();
        Robot bumblebee = extensionLoader.getExtension("bumblebee");
        bumblebee.sayHello();
    }
}

测试结果如下：

Dubbo SPI优点：

能够实现按需加载，JDK SPI仅仅通过接口类名获取所有实现，在通过迭代器获取指定实现，而ExtensionLoader则通过接口类名和key值获取一个实现
支持AOP(将实现类包装在Wrapper中，Wrapper中实现公共增强逻辑)
支持IOC(能够通过set方法注入其他扩展点)

IOC 和 AOP 等特性，这些特性将会在接下来的源码分析章节中一一进行介绍。

源码分析

上一章简单演示了 Dubbo SPI 的使用方法，首先通过 ExtensionLoader 的 getExtensionLoader 方法获取一个 ExtensionLoader 实例，然后再通过 ExtensionLoader 的 getExtension 方法获取拓展类对象。下面我们从 ExtensionLoader 的 getExtension 方法作为入口，对拓展类对象的获取过程进行详细的分析。

    public T getExtension(String name) {
        if (StringUtils.isEmpty(name)) {
            throw new IllegalArgumentException("Extension name == null");
        }
        if ("true".equals(name)) {
             // 获取默认的拓展实现类
            return getDefaultExtension();
        }
        // Holder，顾名思义，用于持有目标对象
        Holder<Object> holder = getOrCreateHolder(name);
        Object instance = holder.get();
         // 双重检查
        if (instance == null) {
            synchronized (holder) {
                instance = holder.get();
                if (instance == null) {
                    // 创建拓展实例
                    instance = createExtension(name);
                    // 设置实例到 holder 中
                    holder.set(instance);
                }
            }
        }
        return (T) instance;
    }

上面代码的逻辑比较简单，首先检查缓存，缓存未命中则创建拓展对象。下面我们来看一下创建拓展对象的过程是怎样的。

private T createExtension(String name) {
    // 从配置文件中加载所有的拓展类，可得到“配置项名称”到“配置类”的映射关系表
    Class<?> clazz = getExtensionClasses().get(name);
    if (clazz == null) {
        throw findException(name);
    }
    try {
        T instance = (T) EXTENSION_INSTANCES.get(clazz);
        if (instance == null) {
            // 通过反射创建实例
            EXTENSION_INSTANCES.putIfAbsent(clazz, clazz.newInstance());
            instance = (T) EXTENSION_INSTANCES.get(clazz);
        }
        // 向实例中注入依赖
        injectExtension(instance);
        Set<Class<?>> wrapperClasses = cachedWrapperClasses;
        if (CollectionUtils.isNotEmpty(wrapperClasses)) {
              // 循环创建 Wrapper 实例
            for (Class<?> wrapperClass : wrapperClasses) {
                // 将当前 instance 作为参数传给 Wrapper 的构造方法，并通过反射创建 Wrapper 实例。
                // 然后向 Wrapper 实例中注入依赖，最后将 Wrapper 实例再次赋值给 instance 变量
                instance = injectExtension(
                    (T) wrapperClass.getConstructor(type).newInstance(instance));
            }
        }
        return instance;
    } catch (Throwable t) {
        throw new IllegalStateException("...");
    }
}

createExtension 方法的逻辑稍复杂一下，包含了如下的步骤：

通过 getExtensionClasses 获取所有的拓展类
通过反射创建拓展对象
向拓展对象中注入依赖
将拓展对象包裹在相应的 Wrapper 对象中

以上步骤中，第一个步骤是加载拓展类的关键，第三和第四个步骤是 Dubbo IOC 与 AOP 的具体实现。由于此类设计源码较多，这里简单的总结下ExtensionLoader整个执行逻辑：

getExtension(String name)  #根据key获取拓展对象
    -->createExtension(String name) #创建拓展实例
        -->getExtensionClasses #根据路径获取所有的拓展类
            -->loadExtensionClasses #加载拓展类
                -->cacheDefaultExtensionName #解析@SPI注解
            -->loadDirectory #方法加载指定文件夹配置文件
                -->loadResource #加载资源
                    -->loadClass #加载类，并通过 loadClass 方法对类进行缓存

SPI中的IOC和AOP

依赖注入

Dubbo IOC 是通过 setter 方法注入依赖。Dubbo 首先会通过反射获取到实例的所有方法，然后再遍历方法列表，检测方法名是否具有 setter 方法特征。若有，则通过 ObjectFactory 获取依赖对象，最后通过反射调用 setter 方法将依赖设置到目标对象中。整个过程对应的代码如下：

private T injectExtension(T instance) {
    try {
        if (objectFactory != null) {
            // 遍历目标类的所有方法
            for (Method method : instance.getClass().getMethods()) {
                // 检测方法是否以 set 开头，且方法仅有一个参数，且方法访问级别为 public
                if (method.getName().startsWith("set")
                    && method.getParameterTypes().length == 1
                    && Modifier.isPublic(method.getModifiers())) {
                    // 获取 setter 方法参数类型
                    Class<?> pt = method.getParameterTypes()[0];
                    try {
                        // 获取属性名，比如 setName 方法对应属性名 name
                        String property = getSetterProperty(method);
                        /* getSetterProperty :
                        method.getName().length() > 3 ? 
                            method.getName().substring(3, 4).toLowerCase() + 
                                method.getName().substring(4) : "";
                        */
                        // 从 ObjectFactory 中获取依赖对象
                        Object object = objectFactory.getExtension(pt, property);
                        if (object != null) {
                            // 通过反射调用 setter 方法设置依赖
                            method.invoke(instance, object);
                        }
                    } catch (Exception e) {
                        logger.error("fail to inject via method...");
                    }
                }
            }
        }
    } catch (Exception e) {
        logger.error(e.getMessage(), e);
    }
    return instance;
}

在上面代码中，objectFactory 变量的类型为 AdaptiveExtensionFactory，AdaptiveExtensionFactory 内部维护了一个 ExtensionFactory 列表，用于存储其他类型的 ExtensionFactory。Dubbo 目前提供了两种 ExtensionFactory，分别是 SpiExtensionFactory 和 SpringExtensionFactory。前者用于创建自适应的拓展，后者是用于从 Spring 的 IOC 容器中获取所需的拓展。这两个类的类的代码不是很复杂，这里就不一一分析了。

Dubbo IOC 目前仅支持 setter 方式注入，总的来说，逻辑比较简单易懂。

动态增强

在用Spring的时候，我们经常会用到AOP功能。在目标类的方法前后插入其他逻辑。比如通常使用Spring AOP来实现日志，监控和鉴权等功能。 Dubbo的扩展机制，是否也支持类似的功能呢？答案是yes。

在Dubbo中，有一种特殊的类，被称为Wrapper类。通过装饰者模式，使用包装类包装原始的扩展点实例。在原始扩展点实现前后插入其他逻辑，实现AOP功能。

装饰者模式

装饰者模式：在不改变原类文件以及不使用继承的情况下，动态地将责任附加到对象上，从而实现动态拓展一个对象的功能。它是通过创建一个包装对象，也就是装饰来包裹真实的对象。

一般来说装饰者模式有下面几个参与者：

Component：装饰者和被装饰者共同的父类，是一个接口或者抽象类，用来定义基本行为
ConcreteComponent：定义具体对象，即被装饰者
Decorator：抽象装饰者，继承自Component，从外类来扩展ConcreteComponent。对于ConcreteComponent来说，不需要知道Decorator的存在，Decorator是一个接口或抽象类
ConcreteDecorator：具体装饰者，用于扩展ConcreteComponent

注：装饰者和被装饰者对象有相同的超类型，因为装饰者和被装饰者必须是一样的类型，这里利用继承是为了达到类型匹配，而不是利用继承获得行为。

dubbo中的AOP

Dubbo AOP 是通过装饰者模式完成的，接下来通过一个简单的案例来学习dubbo中AOP的实现方式。

首先定义一个接口

package com.itheima.dubbo;


import org.apache.dubbo.common.extension.SPI;


@SPI
public interface Phone {
    void call();
}

定义接口的实现类，也就是被装饰者

package com.itheima.dubbo;


public class IphoneX implements Phone {


    @Override
    public void call() {
        System.out.println("iphone正在拨打电话");
    }
}

为了简单，这里省略了装饰者接口。仅仅定义一个装饰者，实现phone接口，内部配置增强逻辑方法

package com.itheima.dubbo;


public class MusicPhone implements Phone {


    private Phone phone;


    public MusicPhone(Phone phone) {
        this.phone = phone;
    }


    @Override
    public void call() {
        System.out.println("播放彩铃");
        this.phone.call();
    }
}

添加拓展点配置文件META-INF/dubbo/com.itheima.dubbo.Phone,内容如下

iphone=com.itheima.dubbo.IphoneX
wrapper=com.itheima.dubbo.MusicPhone

配置测试方法

    public static void main(String[] args) {
        ExtensionLoader<Phone> extensionLoader =
                ExtensionLoader.getExtensionLoader(Phone.class);
        Phone phone = extensionLoader.getExtension("iphone");
        phone.call();
    }

具体执行效果如下

先调用装饰者增强，再调用目标方法完成业务逻辑。

通过测试案例，可以看到在Dubbo SPI中具有增强AOP的功能，我们只需要关注dubbo源码中这样一行代码就够了

//检查是否具有装饰者类，如果有调用装饰者类的构造方法，并返回实例对象
if (CollectionUtils.isNotEmpty(wrapperClasses)) {
    for (Class<?> wrapperClass : wrapperClasses) {
        instance = injectExtension(
            (T) wrapperClass.getConstructor(type).newInstance(instance));
    }
}

动态编译

SPI中的自适应

我们知道在 Dubbo 中，很多拓展都是通过 SPI 机制进行加载的，比如 Protocol、Cluster、LoadBalance、ProxyFactory 等。有时，有些拓展并不想在框架启动阶段被加载，而是希望在拓展方法被调用时，根据运行时参数进行加载，即根据参数动态加载实现类。如下所示：

根据参数动态选择的意思是：

通过ExtensionLoader.getExtensionLoader(XXXClass).getExtension(key)的形式来获取接口的某个实现类。

但这种形式本质上还是通过硬编码的形式在代码中固定的获取了接口的一个实现，诸如Protocol(实现有Dubbo、Redis、Thrift等)，或者Transporter(实现有Netty、Mina等)这些接口，我们是可以在Dubbo服务声明时指定具体实现的

这种在运行时，根据方法参数才动态决定使用具体的拓展，在dubbo中就叫做扩展点自适应实例。其实是一个扩展点的代理，将扩展的选择从Dubbo启动时，延迟到RPC调用时。Dubbo中每一个扩展点都有一个自适应类，如果没有显式提供，Dubbo会自动为我们创建一个，默认使用Javaassist。

自适应拓展机制的实现逻辑是这样的

首先 Dubbo 会为拓展接口生成具有代理功能的代码；
通过 javassist 或 jdk 编译这段代码，得到 Class 类；
通过反射创建代理类；
在代理类中，通过URL对象的参数来确定到底调用哪个实现类；

javassist入门

Javassist是一个开源的分析、编辑和创建Java字节码的类库。是由东京工业大学的数学和计算机科学系的 Shigeru Chiba （千叶滋）所创建的。它已加入了开放源代码JBoss 应用服务器项目,通过使用Javassist对字节码操作为JBoss实现动态AOP框架。javassist是jboss的一个子项目，其主要的优点，在于简单，而且快速。直接使用java编码的形式，而不需要了解虚拟机指令，就能动态改变类的结构，或者动态生成类。为了方便更好的理解dubbo中的自适应，这里通过案例的形式来熟悉下Javassist的基本使用

package com.itheima.compiler;


import java.io.File;
import java.io.FileOutputStream;
import java.lang.reflect.Constructor;
import java.lang.reflect.Modifier;


import javassist.ClassPool;
import javassist.CtClass;
import javassist.CtConstructor;
import javassist.CtField;
import javassist.CtMethod;
import javassist.CtNewMethod;


/**
 *  Javassist是一个开源的分析、编辑和创建Java字节码的类库
 *  能动态改变类的结构，或者动态生成类
 */
public class CompilerByJavassist {


    public static void main(String[] args) throws Exception {


        // ClassPool：class对象容器
        ClassPool pool = ClassPool.getDefault();


        // 通过ClassPool生成一个User类
        CtClass ctClass = pool.makeClass("com.itheima.domain.User");


        // 添加属性     -- private String username
        CtField enameField = new CtField(pool.getCtClass("java.lang.String"),
                "username", ctClass);


        enameField.setModifiers(Modifier.PRIVATE);


        ctClass.addField(enameField);


        // 添加属性    -- private int age
        CtField enoField = new CtField(pool.getCtClass("int"), "age", ctClass);


        enoField.setModifiers(Modifier.PRIVATE);


        ctClass.addField(enoField);


        //添加方法
        ctClass.addMethod(CtNewMethod.getter("getUsername", enameField));
        ctClass.addMethod(CtNewMethod.setter("setUsername", enameField));
        ctClass.addMethod(CtNewMethod.getter("getAge", enoField));
        ctClass.addMethod(CtNewMethod.setter("setAge", enoField));




        // 无参构造器
        CtConstructor constructor = new CtConstructor(null, ctClass);
        constructor.setBody("{}");
        ctClass.addConstructor(constructor);


        // 添加构造函数
        //ctClass.addConstructor(new CtConstructor(new CtClass[] {}, ctClass));


        CtConstructor ctConstructor = new CtConstructor(new CtClass[] {pool.get(String.class.getName()),CtClass.intType}, ctClass);
        ctConstructor.setBody("{\n this.username=$1; \n this.age=$2;\n}");
        ctClass.addConstructor(ctConstructor);


        // 添加自定义方法
        CtMethod ctMethod = new CtMethod(CtClass.voidType, "printUser",new CtClass[] {}, ctClass);
        // 为自定义方法设置修饰符
        ctMethod.setModifiers(Modifier.PUBLIC);
        // 为自定义方法设置函数体
        StringBuffer buffer2 = new StringBuffer();
        buffer2.append("{\nSystem.out.println("用户信息如下");\n")
                .append("System.out.println("用户名="+username);\n")
                .append("System.out.println("年龄="+age);\n").append("}");
        ctMethod.setBody(buffer2.toString());
        ctClass.addMethod(ctMethod);


        //生成一个class
        Class<?> clazz = ctClass.toClass();


        Constructor cons2 = clazz.getDeclaredConstructor(String.class,Integer.TYPE);


        Object obj = cons2.newInstance("itheima",20);


        //反射 执行方法
        obj.getClass().getMethod("printUser", new Class[] {})
                .invoke(obj, new Object[] {});


        // 把生成的class文件写入文件
        byte[] byteArr = ctClass.toBytecode();
        FileOutputStream fos = new FileOutputStream(new File("C://User.class"));
        fos.write(byteArr);
        fos.close();
    }
}

通过以上代码，我们可以知道使用javassist可以方便的在运行时，按需动态的创建java对象，并执行内部方法。而这也是dubbo中动态编译的核心

源码分析

Adaptive注解

在开始之前，我们有必要先看一下与自适应拓展息息相关的一个注解，即 Adaptive 注解。

@Documented
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.TYPE, ElementType.METHOD})
public @interface Adaptive {
    String[] value() default {};
}

从上面的代码中可知，Adaptive 可注解在类或方法上。

标注在类上：Dubbo 不会为该类生成代理类。Adaptive 注解在类上的情况很少，在 Dubbo 中，仅有两个类被 Adaptive 注解了，分别是 AdaptiveCompiler 和 AdaptiveExtensionFactory。此种情况，表示拓展的加载逻辑由人工编码完成。更多时候，Adaptive 是注解在接口方法上的，表示拓展的加载逻辑需由框架自动生成
标注在方法上：Dubbo 则会为该方法生成代理逻辑，表示当前方法需要根据参数URL 调用对应的扩展点实现。例如 Protocol的SPI类有 injvm dubbo registry filter listener等等很多扩展未知类，它设计了Protocol$Adaptive的类，通过ExtensionLoader.getExtensionLoader(Protocol.class).getExtension(spi类);来提取对象

获取自适应拓展类

dubbo中每一个扩展点都有一个自适应类，如果没有显式提供，Dubbo会自动为我们创建一个，默认使用Javaassist。先来看下创建自适应扩展类的代码：

// 精简代码如下
public T getAdaptiveExtension() {
    Object instance = cachedAdaptiveInstance.get();
    if (instance == null) {
            synchronized (cachedAdaptiveInstance) {
                instance = cachedAdaptiveInstance.get();
                if (instance == null) {
                      instance = createAdaptiveExtension();
                      cachedAdaptiveInstance.set(instance); 
                }
            }        
    }


    return (T) instance;
}

继续看createAdaptiveExtension方法

private T createAdaptiveExtension() {        
    return injectExtension((T) getAdaptiveExtensionClass().newInstance());
}

继续看getAdaptiveExtensionClass方法

private Class<?> getAdaptiveExtensionClass() {
        getExtensionClasses();
        if (cachedAdaptiveClass != null) {
            return cachedAdaptiveClass;
        }
        return cachedAdaptiveClass = createAdaptiveExtensionClass();
    }

继续看createAdaptiveExtensionClass方法，绕了一大圈，终于来到了具体的实现了。看这个createAdaptiveExtensionClass方法，它首先会生成自适应类的Java源码，然后再将源码编译成Java的字节码，加载到JVM中。

private Class<?> createAdaptiveExtensionClass() {
        String code = createAdaptiveExtensionClassCode();
        ClassLoader classLoader = findClassLoader();
        org.apache.dubbo.common.compiler.Compiler compiler = ExtensionLoader.getExtensionLoader(org.apache.dubbo.common.compiler.Compiler.class).getAdaptiveExtension();
        return compiler.compile(code, classLoader);
    }

Compiler的代码，默认实现是javassist。

@SPI("javassist")
public interface Compiler {
    Class<?> compile(String code, ClassLoader classLoader);
}

createAdaptiveExtensionClassCode()方法中使用一个StringBuilder来构建自适应类的Java源码。方法实现比较长，这里就不贴代码了。这种生成字节码的方式也挺有意思的，先生成Java源代码，然后编译，加载到jvm中。通过这种方式，可以更好的控制生成的Java类。而且这样也不用care各个字节码生成框架的api等。因为xxx.java文件是Java通用的，也是我们最熟悉的。只是代码的可读性不强，需要一点一点构建xx.java的内容。

示例：以 Protocol 接口为例，Protocol接口定义如下：

@SPI("dubbo")
public interface Protocol {


    int getDefaultPort();


    @Adaptive
    <T> Exporter<T> export(Invoker<T> invoker) throws RpcException;


    @Adaptive
    <T> Invoker<T> refer(Class<T> type, URL url) throws RpcException;


    void destroy();
    default List<ProtocolServer> getServers() {
        return Collections.emptyList();
    }


}

下面给大家展示一下生成的 Protocol$Adaptive 的源码，如下

package org.apache.dubbo.rpc;
import org.apache.dubbo.common.extension.ExtensionLoader;
public class Protocol$Adaptive implements org.apache.dubbo.rpc.Protocol {
    
    public org.apache.dubbo.rpc.Invoker refer(java.lang.Class arg0, org.apache.dubbo.common.URL arg1) throws org.apache.dubbo.rpc.RpcException {
        if (arg1 == null) throw new IllegalArgumentException("url == null");
        org.apache.dubbo.common.URL url = arg1;
        String extName = ( url.getProtocol() == null ? "dubbo" : url.getProtocol() );
        if(extName == null) throw new IllegalStateException("Failed to get extension (org.apache.dubbo.rpc.Protocol) name from url (" + url.toString() + ") use keys([protocol])");
        org.apache.dubbo.rpc.Protocol extension = (org.apache.dubbo.rpc.Protocol)ExtensionLoader.getExtensionLoader(org.apache.dubbo.rpc.Protocol.class).getExtension(extName);
        return extension.refer(arg0, arg1);
    }
    
    public java.util.List getServers()  {
        throw new UnsupportedOperationException("The method public default java.util.List org.apache.dubbo.rpc.Protocol.getServers() of interface org.apache.dubbo.rpc.Protocol is not adaptive method!");
    }
    
    public org.apache.dubbo.rpc.Exporter export(org.apache.dubbo.rpc.Invoker arg0) throws org.apache.dubbo.rpc.RpcException {
        if (arg0 == null) throw new IllegalArgumentException("org.apache.dubbo.rpc.Invoker argument == null");
        if (arg0.getUrl() == null) throw new IllegalArgumentException("org.apache.dubbo.rpc.Invoker argument getUrl() == null");
        org.apache.dubbo.common.URL url = arg0.getUrl();
        String extName = ( url.getProtocol() == null ? "dubbo" : url.getProtocol() );
        if(extName == null) throw new IllegalStateException("Failed to get extension (org.apache.dubbo.rpc.Protocol) name from url (" + url.toString() + ") use keys([protocol])");
        org.apache.dubbo.rpc.Protocol extension = (org.apache.dubbo.rpc.Protocol)ExtensionLoader.getExtensionLoader(org.apache.dubbo.rpc.Protocol.class).getExtension(extName);
        return extension.export(arg0);
    }
    
    public void destroy()  {
        throw new UnsupportedOperationException("The method public abstract void org.apache.dubbo.rpc.Protocol.destroy() of interface org.apache.dubbo.rpc.Protocol is not adaptive method!");
    }
    public int getDefaultPort()  {
        throw new UnsupportedOperationException("The method public abstract int org.apache.dubbo.rpc.Protocol.getDefaultPort() of interface org.apache.dubbo.rpc.Protocol is not adaptive method!");
    }
}

以调用 Protocol 的接口的 refer方法为例，下面给大家看一下自适应拓展的整个过程：

1）、先通过 Protocol REF_PROTOCOL = ExtensionLoader.getExtensionLoader(Protocol.class).getAdaptiveExtension(); 生成了 Protocol$Adaptive 代理类

2）、传参 Url 为：dubbo://192.168.1.247:20887/org.apache.dubbo.config.spring.api.DemoService，调用 Protocol 的 refer 方法，此时直接调用是 Protocol$Adaptive 代理类的 refer 方法

3）、在 Protocol$Adaptive 的 refer 方法中先调用 url 中的 getProtocol() 方法获取拓展类名称，赋值给 extName 变量

4）、然后调用 org.apache.dubbo.rpc.Protocol extension = (org.apache.dubbo.rpc.Protocol)ExtensionLoader.getExtensionLoader(org.apache.dubbo.rpc.Protocol.class).getExtension(extName); 语句获取到具体的实现类的实例

5）、最后执行 extension.refer(arg0, arg1) 语句，调用 4 中获取到的具体实现类的 refer 方法，最终返回结果

服务暴露(导出)与发现

概述

dubbo是一个简单易用的RPC框架，通过简单的提供者，消费者配置就能完成无感的网络调用。那么在dubbo中是如何将提供者的服务暴露出去，消费者又是如何获取到提供者相关信息的呢？这就是本章我们要讨论的内容。

Spring中自定义Schema

在了解dubbo的服务注册和服务发现之前，我们首先需要掌握一个知识点：Spring中自定义Schema。

dubbo Provider 在容器启动后开始暴露服务，并准备接受请求处理。所以可以理解为容器的启动带动dubbo Provider开始工作。

Dubbo 现在的设计是完全无侵入，也就是使用者只依赖于配置契约。在 Dubbo 中，可以使用 XML 配置相关信息来引入服务或者导出服务（也可以使用注解）。配置完成，启动工程，Spring 会读取配置文件，生成注入相关Bean。那 Dubbo 如何实现自定义 XML 被 Spring 加载读取呢？（涉及到dubbo和spring的集成）

从 Spring 2.0 开始，Spring 开始提供了一种基于 XML Schema 格式扩展机制，用于自定义和配置 bean，从而被spring框架所解析。

案例使用

学习和使用Spring XML Schema 扩展机制并不难，需要下面几个步骤：

创建配置属性的JavaBean对象
创建一个 XML Schema 文件，描述自定义的合法构建模块，也就是xsd文件。
自定义处理器类，并实现NamespaceHandler接口。
自定义解析器，实现BeanDefinitionParser接口(最关键的部分)。
编写Spring.handlers和spring.schemas文件配置所有部件

定义JavaBean对象，在spring中此对象会根据配置自动创建

public class User {
    private String id;  
    private String name;  
    private Integer age;
    //省略getter setter方法
}

在META-INF下定义user.xsd文件，使用xsd用于描述标签的规则

<?xml version="1.0" encoding="UTF-8"?>  
<xsd:schema   
    xmlns="http://www.itheima.com/schema/user"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"   
    xmlns:beans="http://www.springframework.org/schema/beans"  
    targetNamespace="http://www.itheima.com/schema/user"
    elementFormDefault="qualified"   
    attributeFormDefault="unqualified">  
    <xsd:import namespace="http://www.springframework.org/schema/beans" />  
    <xsd:element name="user">
        <xsd:complexType>  
            <xsd:complexContent>  
                <xsd:extension base="beans:identifiedType">  
                    <xsd:attribute name="name" type="xsd:string" />  
                    <xsd:attribute name="age" type="xsd:int" />  
                </xsd:extension>  
            </xsd:complexContent>  
        </xsd:complexType>  
    </xsd:element>  
</xsd:schema>

Spring读取xml文件时，会根据标签的命名空间找到其对应的NamespaceHandler，我们在NamespaceHandler内会注册标签对应的解析器BeanDefinitionParser。

package com.itheima.schema;


import org.springframework.beans.factory.xml.NamespaceHandlerSupport;


public class UserNamespaceHandler extends NamespaceHandlerSupport {
    public void init() {
        registerBeanDefinitionParser("user", new UserBeanDefinitionParser());
    }
}

BeanDefinitionParser是标签对应的解析器，Spring读取到对应标签时会使用该类进行解析；

public class UserBeanDefinitionParser extends
        AbstractSingleBeanDefinitionParser {
    
    protected Class getBeanClass(Element element) {
        return User.class;
    }


    protected void doParse(Element element, BeanDefinitionBuilder bean) {
        String name = element.getAttribute("name");
        String age = element.getAttribute("age");
        String id = element.getAttribute("id");
        if (StringUtils.hasText(id)) {
            bean.addPropertyValue("id", id);
        }
        if (StringUtils.hasText(name)) {
            bean.addPropertyValue("name", name);
        }
        if (StringUtils.hasText(age)) {
            bean.addPropertyValue("age", Integer.valueOf(age));
        }
    }
}

定义spring.handlers文件，内部保存命名空间与NamespaceHandler类的对应关系；必须放在classpath下的META-INF文件夹中。

http://www.itheima.com/schema/user=com.itheima.schema.UserNamespaceHandler

定义spring.schemas文件，内部保存命名空间对应的xsd文件位置；必须放在classpath下的META-INF文件夹中。

http://www.itheima.com/schema/user.xsd=META-INF/user.xsd

代码准备好了之后，就可以在spring工程中进行使用和测试，定义spring配置文件，导入对应约束

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xmlns:context="http://www.springframework.org/schema/context" 
xmlns:util="http://www.springframework.org/schema/util" 
xmlns:task="http://www.springframework.org/schema/task" 
xmlns:aop="http://www.springframework.org/schema/aop" 
xmlns:tx="http://www.springframework.org/schema/tx"
xmlns:itheima="http://www.itheima.com/schema/user"
 xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
        http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd
        http://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util.xsd
        http://www.springframework.org/schema/task http://www.springframework.org/schema/task/spring-task.xsd
        http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop.xsd
        http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx.xsd
http://www.itheima.com/schema/user http://www.itheima.com/schema/user.xsd">


    <itheima:user id="user" name="zhangsan" age="12"></itheima:user>


</beans>

编写测试类，通过spring容器获取对象user

public class SchemaDemo {
    public static void main(String[] args) {
        ApplicationContext ctx = new ClassPathXmlApplicationContext("/spring/applicationContext.xml");
        User user = (User)ctx.getBean("user");
        System.out.println(user);
    }
}

dubbo中的相关对象

Dubbo是运行在spring容器中，dubbo的配置文件也是通过spring的配置文件applicationContext.xml来加载，所以dubbo的自定义配置标签实现，其实同样依赖spring的xml schema机制

1、在dubbo-demo-xml模块中可以查看dubbo如何在spring的配置文件中进行配置

2、spring如何来解析这些配置并注册对应的bean呢？通过前面的知识我们知道了是通过spring 的 Schema机制

找到dubbo-config/dubbo-config-spring模块，

核心在DubboNamespaceHandler中，

可以看出Dubbo所有的组件都是由DubboBeanDefinitionParser解析，并通过registerBeanDefinitionParser方法来注册到spring中最后解析对应的对象。这些对象中我们重点关注的有以下两个：

ServiceBean：服务提供者暴露服务的核心对象
ReferenceBean：服务消费者发现服务的核心对象
RegistryConfig：定义注册中心的核心配置对象

服务暴露机制

前面主要探讨了 Dubbo 中 schema 、 XML 的相关原理，这些内容对理解框架整体至关重要，在此基础上我们继续探讨服务是如何依靠前面的配置进行服务暴露

术语解释

在 Dubbo 的核心领域模型中：

Invoker 是实体域，它是 Dubbo 的核心模型，其它模型都向它靠扰，或转换成它，它代表一个可执行体，可向它发起 invoke 调用，它有可能是一个本地的实现，也可能是一个远程的实现，也可能一个集群实现。在服务提供方，Invoker用于调用服务提供类。在服务消费方，Invoker用于执行远程调用。

由于 Invoker 是 Dubbo 领域模型中非常重要的一个概念，很多设计思路都是向它靠拢。这就使得 Invoker 渗透在整个实现代码里，对于刚开始接触 Dubbo 的人，确实容易给搞混了。下面我们用一个精简的图来说明最重要的两种 Invoker：服务提供 Invoker 和服务消费 Invoker

Protocol 是服务域，它是 Invoker 暴露和引用的主功能入口，它负责 Invoker 的生命周期管理。
- export：暴露远程服务
- refer：引用远程服务
proxyFactory：获取一个接口的代理类
- getInvoker：针对server端，将服务对象，如DemoServiceImpl包装成一个Invoker对象
- getProxy：针对client端，创建接口的代理对象，例如DemoService接口的代理实现。
Invocation 是会话域，它持有调用过程中的变量，比如方法名，参数等

流程机制

在详细探讨服务暴露细节之前，我们先看一下整体dubbo的服务暴露原理

在整体上看，Dubbo 框架做服务暴露分为两大部分，

1、第一步将持有的服务实例通过代理转换成 Invoker,

2、第二步会把 Invoker 通过具体的协议（比如 Dubbo ）转换成 Exporter, 框架做了这层抽象也大大方便了功能扩展。

服务提供方暴露服务的蓝色初始化链，时序图如下：

源码分析

导出入口

服务导出的入口方法是 ServiceBean 的 onApplicationEvent。onApplicationEvent 是一个事件响应方法，该方法会在收到 Spring 上下文刷新事件后执行服务导出操作。方法代码如下：

public void onApplicationEvent(ContextRefreshedEvent event) {
    // 是否有延迟导出 && 是否已导出 && 是不是已被取消导出
    if (isDelay() && !isExported() && !isUnexported()) {
        // 导出服务
        export();
    }
}

onApplicationEvent 方法在经过一些判断后，会决定是否调用 export 方法导出服务。在export 根据配置执行相应的动作。最终进入到ServiceConfig.doExportUrls导出服务方法

private void doExportUrls() {
    // 加载注册中心链接
    List<URL> registryURLs = loadRegistries(true);
    // 遍历 protocols，并在每个协议下导出服务
    for (ProtocolConfig protocolConfig : protocols) {
        .....
        //核心，其他略
        doExportUrlsFor1Protocol(protocolConfig, registryURLs);
    }
}

关于多协议多注册中心导出服务首先是根据配置，以及其他一些信息组装 URL。前面说过，URL 是 Dubbo 配置的载体，通过 URL 可让 Dubbo 的各种配置在各个模块之间传递。

private void doExportUrlsFor1Protocol(ProtocolConfig protocolConfig, List<URL> registryURLs) {
    String name = protocolConfig.getName();
    // 如果协议名为空，或空串，则将协议名变量设置为 dubbo
    if (name == null || name.length() == 0) {
        name = "dubbo";
    }


    Map<String, String> map = new HashMap<String, String>();
    
    //略


    // 获取上下文路径
    String contextPath = protocolConfig.getContextpath();
    if ((contextPath == null || contextPath.length() == 0) && provider != null) {
        contextPath = provider.getContextpath();
    }


    // 获取 host 和 port
    String host = this.findConfigedHosts(protocolConfig, registryURLs, map);
    Integer port = this.findConfigedPorts(protocolConfig, name, map);
    // 组装 URL
    URL url = new URL(name, host, port, (contextPath == null || contextPath.length() == 0 ? "" : contextPath + "/") + path, map);
    
    // 省略无关代码
}

上面的代码首先是将一些信息，比如版本、时间戳、方法名以及各种配置对象的字段信息放入到 map 中，最后将 map 和主机名等数据传给 URL 构造方法创建 URL 对象。前置工作做完，接下来就可以进行服务导出了。服务导出分为导出到本地 (JVM)，和导出到远程。在深入分析服务导出的源码前，我们先来从宏观层面上看一下服务导出逻辑。如下：

private void doExportUrlsFor1Protocol(ProtocolConfig protocolConfig, List<URL> registryURLs) {
    
    // 省略无关代码
    String scope = url.getParameter(Constants.SCOPE_KEY);
    // 如果 scope = none，则什么都不做
    if (!Constants.SCOPE_NONE.toString().equalsIgnoreCase(scope)) {
        // scope != remote，导出到本地
        if (!Constants.SCOPE_REMOTE.toString().equalsIgnoreCase(scope)) {
            exportLocal(url);
        }
        // scope != local，导出到远程
        if (!Constants.SCOPE_LOCAL.toString().equalsIgnoreCase(scope)) {
            if (registryURLs != null && !registryURLs.isEmpty()) {
                for (URL registryURL : registryURLs) {
                    //省略无关代码
                    
                    // 为服务提供类(ref)生成 Invoker
                    Invoker<?> invoker = proxyFactory.getInvoker(ref, (Class) interfaceClass, registryURL.addParameterAndEncoded(Constants.EXPORT_KEY, url.toFullString()));
                    // DelegateProviderMetaDataInvoker 用于持有 Invoker 和 ServiceConfig
                    DelegateProviderMetaDataInvoker wrapperInvoker = new DelegateProviderMetaDataInvoker(invoker, this);


                    // 导出服务，并生成 Exporter
                    Exporter<?> exporter = protocol.export(wrapperInvoker);
                    exporters.add(exporter);
                }
                
            // 不存在注册中心，仅导出服务
            } else {
                //略
            }
        }
    }
    this.urls.add(url);
}

上面代码根据 url 中的 scope 参数决定服务导出方式，分别如下：

scope = none，不导出服务
scope != remote，导出到本地
scope != local，导出到远程

不管是导出到本地，还是远程。进行服务导出之前，均需要先创建 Invoker，这是一个很重要的步骤。因此下面先来分析 Invoker 的创建过程。Invoker 是由 ProxyFactory 创建而来，Dubbo 默认的 ProxyFactory 实现类是 JavassistProxyFactory。下面我们到 JavassistProxyFactory 代码中，探索 Invoker 的创建过程。如下：

public <T> Invoker<T> getInvoker(T proxy, Class<T> type, URL url) {
    // 为目标类创建 Wrapper
    final Wrapper wrapper = Wrapper.getWrapper(proxy.getClass().getName().indexOf('$') < 0 ? proxy.getClass() : type);
    // 创建匿名 Invoker 类对象，并实现 doInvoke 方法。
    return new AbstractProxyInvoker<T>(proxy, type, url) {
        @Override
        protected Object doInvoke(T proxy, String methodName,
                                  Class<?>[] parameterTypes,
                                  Object[] arguments) throws Throwable {
            // 调用 Wrapper 的 invokeMethod 方法，invokeMethod 最终会调用目标方法
            return wrapper.invokeMethod(proxy, methodName, parameterTypes, arguments);
        }
    };
}

如上，JavassistProxyFactory 创建了一个继承自 AbstractProxyInvoker 类的匿名对象，并覆写了抽象方法 doInvoke。

导出服务到本地

Invoke创建成功之后，接下来我们来看本地导出

private void exportLocal(URL url) {
    // 如果 URL 的协议头等于 injvm，说明已经导出到本地了，无需再次导出
    if (!Constants.LOCAL_PROTOCOL.equalsIgnoreCase(url.getProtocol())) {
        URL local = URL.valueOf(url.toFullString())
            .setProtocol(Constants.LOCAL_PROTOCOL)    // 设置协议头为 injvm
            .setHost(LOCALHOST)
            .setPort(0);
        ServiceClassHolder.getInstance().pushServiceClass(getServiceClass(ref));
        // 创建 Invoker，并导出服务，这里的 protocol 会在运行时调用 InjvmProtocol 的 export 方法
        Exporter<?> exporter = protocol.export(
            proxyFactory.getInvoker(ref, (Class) interfaceClass, local));
        exporters.add(exporter);
    }
}

exportLocal 方法比较简单，首先根据 URL 协议头决定是否导出服务。若需导出，则创建一个新的 URL 并将协议头、主机名以及端口设置成新的值。然后创建 Invoker，并调用 InjvmProtocol 的 export 方法导出服务。下面我们来看一下 InjvmProtocol 的 export 方法都做了哪些事情。

public <T> Exporter<T> export(Invoker<T> invoker) throws RpcException {
    // 创建 InjvmExporter
    return new InjvmExporter<T>(invoker, invoker.getUrl().getServiceKey(), exporterMap);
}

如上，InjvmProtocol 的 export 方法仅创建了一个 InjvmExporter，无其他逻辑。到此导出服务到本地就分析完了。

导出服务到远程(重点)

接下来，我们继续分析导出服务到远程的过程。导出服务到远程包含了服务导出与服务注册两个过程。先来分析服务导出逻辑。我们把目光移动到 RegistryProtocol 的 export 方法上。

public <T> Exporter<T> export(final Invoker<T> originInvoker) throws RpcException {
    // 1. 导出服务
    final ExporterChangeableWrapper<T> exporter = doLocalExport(originInvoker);


    // 2. 获取注册中心 URL
    URL registryUrl = getRegistryUrl(originInvoker);


    // 3. 根据 URL 加载 Registry 实现类，比如 ZookeeperRegistry
    final Registry registry = getRegistry(originInvoker);
    
    // 4. 获取已注册的服务提供者 URL
    final URL registeredProviderUrl = getRegisteredProviderUrl(originInvoker);


    // 5. 获取 register 参数
    boolean register = registeredProviderUrl.getParameter("register", true);


    // 6. 向服务提供者与消费者注册表中注册服务提供者
    ProviderConsumerRegTable.registerProvider(originInvoker, registryUrl, registeredProviderUrl);


    // 7. 根据 register 的值决定是否注册服务
    if (register) {
        // 向注册中心注册服务(dubbo协议， zookeeper)
        register(registryUrl, registeredProviderUrl);
        ProviderConsumerRegTable.getProviderWrapper(originInvoker).setReg(true);
    }


    // 8. 获取订阅 URL，比如：
    final URL overrideSubscribeUrl = getSubscribedOverrideUrl(registeredProviderUrl);
    // 9. 创建监听器
    final OverrideListener overrideSubscribeListener = new OverrideListener(overrideSubscribeUrl, originInvoker);
    overrideListeners.put(overrideSubscribeUrl, overrideSubscribeListener);
    // 10. 向注册中心进行订阅 override 数据
    registry.subscribe(overrideSubscribeUrl, overrideSubscribeListener);
    // 11. 创建并返回 DestroyableExporter
    return new DestroyableExporter<T>(exporter, originInvoker, overrideSubscribeUrl, registeredProviderUrl);
}

上面代码看起来比较复杂，主要做如下一些操作：

调用 doLocalExport 导出服务
向注册中心注册服务
向注册中心进行订阅 override 数据
创建并返回 DestroyableExporter

下面先来分析 doLocalExport 方法的逻辑，如下：

private <T> ExporterChangeableWrapper<T> doLocalExport(final Invoker<T> originInvoker) {
    String key = getCacheKey(originInvoker);
    // 1. 访问缓存
    ExporterChangeableWrapper<T> exporter = (ExporterChangeableWrapper<T>) bounds.get(key);
    if (exporter == null) {
        synchronized (bounds) {
            exporter = (ExporterChangeableWrapper<T>) bounds.get(key);
            if (exporter == null) {
                // 创建 Invoker 为委托类对象
                final Invoker<?> invokerDelegete = new InvokerDelegete<T>(originInvoker, getProviderUrl(originInvoker));
                // 调用 protocol 的 export 方法导出服务
                exporter = new ExporterChangeableWrapper<T>((Exporter<T>) protocol.export(invokerDelegete), originInvoker);
            
                // 写缓存
                bounds.put(key, exporter);
            }
        }
    }
    return exporter;
}

接下来，我们把重点放在 Protocol 的 export 方法上。假设运行时协议为 dubbo，此处的 protocol 变量会在运行时加载 DubboProtocol，并调用 DubboProtocol 的 export 方法。

public <T> Exporter<T> export(Invoker<T> invoker) throws RpcException {
    URL url = invoker.getUrl();


    // 1. 获取服务标识，理解成服务坐标也行。由服务组名，服务名，服务版本号以及端口组成。比如：
    // demoGroup/com.alibaba.dubbo.demo.DemoService:1.0.1:20880
    String key = serviceKey(url);
    // 创建 DubboExporter
    DubboExporter<T> exporter = new DubboExporter<T>(invoker, key, exporterMap);
    // 将 <key, exporter> 键值对放入缓存中
    exporterMap.put(key, exporter);


    //省略无关代码


    // 启动服务器
    openServer(url);
    // 优化序列化
    optimizeSerialization(url);
    return exporter;
}

开启Netty服务

如上，我们重点关注 DubboExporter 的创建以及 openServer 方法，其他逻辑看不懂也没关系，不影响理解服务导出过程。下面分析 openServer 方法。

private void openServer(URL url) {
    // 获取 host:port，并将其作为服务器实例的 key，用于标识当前的服务器实例
    String key = url.getAddress();
    boolean isServer = url.getParameter(Constants.IS_SERVER_KEY, true);
    if (isServer) {
        // 访问缓存
        ExchangeServer server = serverMap.get(key);
        if (server == null) {
            // 创建服务器实例
            serverMap.put(key, createServer(url));
        } else {
            // 服务器已创建，则根据 url 中的配置重置服务器
            server.reset(url);
        }
    }
}

接下来分析服务器实例的创建过程。如下：

private ExchangeServer createServer(URL url) {
    url = url.addParameterIfAbsent(Constants.CHANNEL_READONLYEVENT_SENT_KEY,
    // 1. 添加心跳检测配置到 url 中
    url = url.addParameterIfAbsent(Constants.HEARTBEAT_KEY, String.valueOf(Constants.DEFAULT_HEARTBEAT));
    // 2. 获取 server 参数，默认为 netty
    String str = url.getParameter(Constants.SERVER_KEY, Constants.DEFAULT_REMOTING_SERVER);


    // 通过 SPI 检测是否存在 server 参数所代表的 Transporter 拓展，不存在则抛出异常
    if (str != null && str.length() > 0 && !ExtensionLoader.getExtensionLoader(Transporter.class).hasExtension(str))
        throw new RpcException("Unsupported server type: " + str + ", url: " + url);


    // 添加编码解码器参数
    url = url.addParameter(Constants.CODEC_KEY, DubboCodec.NAME);
    ExchangeServer server;
    try {
        // 创建 ExchangeServer
        server = Exchangers.bind(url, requestHandler);
    } catch (RemotingException e) {
        throw new RpcException("Fail to start server...");
    }
                                   
    // 获取 client 参数，可指定 netty，mina
    str = url.getParameter(Constants.CLIENT_KEY);
    if (str != null && str.length() > 0) {
        // 获取所有的 Transporter 实现类名称集合，比如 supportedTypes = [netty, mina]
        Set<String> supportedTypes = ExtensionLoader.getExtensionLoader(Transporter.class).getSupportedExtensions();
        // 检测当前 Dubbo 所支持的 Transporter 实现类名称列表中，
        // 是否包含 client 所表示的 Transporter，若不包含，则抛出异常
        if (!supportedTypes.contains(str)) {
            throw new RpcException("Unsupported client type...");
        }
    }
    return server;
}

如上，createServer 包含三个核心的逻辑。第一是检测是否存在 server 参数所代表的 Transporter 拓展，不存在则抛出异常。第二是创建服务器实例。第三是检测是否支持 client 参数所表示的 Transporter 拓展，不存在也是抛出异常。两次检测操作所对应的代码比较直白了，无需多说。但创建服务器的操作目前还不是很清晰，我们继续往下看。

public static ExchangeServer bind(URL url, ExchangeHandler handler) throws RemotingException {
    if (url == null) {
        throw new IllegalArgumentException("url == null");
    }
    if (handler == null) {
        throw new IllegalArgumentException("handler == null");
    }
    url = url.addParameterIfAbsent(Constants.CODEC_KEY, "exchange");
    // 获取 Exchanger，默认为 HeaderExchanger。
    // 紧接着调用 HeaderExchanger 的 bind 方法创建 ExchangeServer 实例
    return getExchanger(url).bind(url, handler);
}

上面代码比较简单，就不多说了。下面看一下 HeaderExchanger 的 bind 方法。

public ExchangeServer bind(URL url, ExchangeHandler handler) throws RemotingException {
    // 创建 HeaderExchangeServer 实例，该方法包含了多个逻辑，分别如下：
    //   1. new HeaderExchangeHandler(handler)
    //   2. new DecodeHandler(new HeaderExchangeHandler(handler))
    //   3. Transporters.bind(url, new DecodeHandler(new HeaderExchangeHandler(handler)))
    return new HeaderExchangeServer(Transporters.bind(url, new DecodeHandler(new HeaderExchangeHandler(handler))));
}

HeaderExchanger 的 bind 方法包含的逻辑比较多，但目前我们仅需关心 Transporters 的 bind 方法逻辑即可。该方法的代码如下：

public static Server bind(URL url, ChannelHandler... handlers) throws RemotingException {
    if (url == null) {
        throw new IllegalArgumentException("url == null");
    }
    if (handlers == null || handlers.length == 0) {
        throw new IllegalArgumentException("handlers == null");
    }
    ChannelHandler handler;
    if (handlers.length == 1) {
        handler = handlers[0];
    } else {
        // 如果 handlers 元素数量大于1，则创建 ChannelHandler 分发器
        handler = new ChannelHandlerDispatcher(handlers);
    }
    // 获取自适应 Transporter 实例，并调用实例方法
    return getTransporter().bind(url, handler);
}

如上，getTransporter() 方法获取的 Transporter 是在运行时动态创建的，类名为 TransporterAdaptive，也就是自适应拓展类。TransporterAdaptive 会在运行时根据传入的 URL 参数决定加载什么类型的 Transporter，默认为 NettyTransporter。

调用NettyTransporter.bind(URL, ChannelHandler)方法。创建一个NettyServer实例。调用NettyServer.doOPen()方法，服务器被开启，服务也被暴露出来了。

服务注册

本节内容以 Zookeeper 注册中心作为分析目标，其他类型注册中心大家可自行分析。下面从服务注册的入口方法开始分析，我们把目光再次移到 RegistryProtocol 的 export 方法上。如下：

public <T> Exporter<T> export(final Invoker<T> originInvoker) throws RpcException {
    
    // ${导出服务}
    
    // 省略其他代码
    
    boolean register = registeredProviderUrl.getParameter("register", true);
    if (register) {
        // 注册服务
        register(registryUrl, registeredProviderUrl);
        ProviderConsumerRegTable.getProviderWrapper(originInvoker).setReg(true);
    }
    
    final URL overrideSubscribeUrl = getSubscribedOverrideUrl(registeredProviderUrl);
    final OverrideListener overrideSubscribeListener = new OverrideListener(overrideSubscribeUrl, originInvoker);
    overrideListeners.put(overrideSubscribeUrl, overrideSubscribeListener);
    // 订阅 override 数据
    registry.subscribe(overrideSubscribeUrl, overrideSubscribeListener);


    // 省略部分代码
}

RegistryProtocol 的 export 方法包含了服务导出，注册，以及数据订阅等逻辑。其中服务导出逻辑上一节已经分析过了，本节将分析服务注册逻辑，相关代码如下：

public void register(URL registryUrl, URL registedProviderUrl) {
    // 获取 Registry
    Registry registry = registryFactory.getRegistry(registryUrl);
    // 注册服务
    registry.register(registedProviderUrl);
}

这里以 Zookeeper 注册中心为例进行分析。下面先来看一下 getRegistry 方法的源码，这个方法由 AbstractRegistryFactory 实现。如下：

public Registry getRegistry(URL url) {
    url = url.setPath(RegistryService.class.getName())
            .addParameter(Constants.INTERFACE_KEY, RegistryService.class.getName())
            .removeParameters(Constants.EXPORT_KEY, Constants.REFER_KEY);
    String key = url.toServiceString();
    LOCK.lock();
    try {
        // 访问缓存
        Registry registry = REGISTRIES.get(key);
        if (registry != null) {
            return registry;
        }
        
        // 缓存未命中，创建 Registry 实例
        registry = createRegistry(url);
        if (registry == null) {
            throw new IllegalStateException("Can not create registry...");
        }
        
        // 写入缓存
        REGISTRIES.put(key, registry);
        return registry;
    } finally {
        LOCK.unlock();
    }
}


protected abstract Registry createRegistry(URL url);

如上，getRegistry 方法先访问缓存，缓存未命中则调用 createRegistry 创建 Registry。在此方法中就是通过new ZookeeperRegistry(url, zookeeperTransporter)实例化一个注册中心

public ZookeeperRegistry(URL url, ZookeeperTransporter zookeeperTransporter) {
    super(url);
    if (url.isAnyHost()) {
        throw new IllegalStateException("registry address == null");
    }
    
    // 获取组名，默认为 dubbo
    String group = url.getParameter(Constants.GROUP_KEY, DEFAULT_ROOT);
    if (!group.startsWith(Constants.PATH_SEPARATOR)) {
        // group = "/" + group
        group = Constants.PATH_SEPARATOR + group;
    }
    this.root = group;
    // 创建 Zookeeper 客户端，默认为 CuratorZookeeperTransporter
    zkClient = zookeeperTransporter.connect(url);
    // 添加状态监听器
    zkClient.addStateListener(new StateListener() {
        @Override
        public void stateChanged(int state) {
            if (state == RECONNECTED) {
                try {
                    recover();
                } catch (Exception e) {
                    logger.error(e.getMessage(), e);
                }
            }
        }
    });
}

在上面的代码代码中，我们重点关注 ZookeeperTransporter 的 connect 方法调用，这个方法用于创建 Zookeeper 客户端。创建好 Zookeeper 客户端，意味着注册中心的创建过程就结束了。接下来，再来分析一下 Zookeeper 客户端的创建过程。

public ZookeeperClient connect(URL url) {
    // 创建 CuratorZookeeperClient
    return new CuratorZookeeperClient(url);
}

继续向下看。

public class CuratorZookeeperClient extends AbstractZookeeperClient<CuratorWatcher> {


    private final CuratorFramework client;
    
    public CuratorZookeeperClient(URL url) {
        super(url);
        try {
            // 创建 CuratorFramework 构造器
            CuratorFrameworkFactory.Builder builder = CuratorFrameworkFactory.builder()
                    .connectString(url.getBackupAddress())
                    .retryPolicy(new RetryNTimes(1, 1000))
                    .connectionTimeoutMs(5000);
            String authority = url.getAuthority();
            if (authority != null && authority.length() > 0) {
                builder = builder.authorization("digest", authority.getBytes());
            }
            // 构建 CuratorFramework 实例
            client = builder.build();
            //省略无关代码
            
            // 启动客户端
            client.start();
        } catch (Exception e) {
            throw new IllegalStateException(e.getMessage(), e);
        }
    }
}

CuratorZookeeperClient 构造方法主要用于创建和启动 CuratorFramework 实例。至此Zookeeper客户端就已经启动了

下面我们将 Dubbo 的 demo 跑起来，然后通过 Zookeeper 可视化客户端 ZooInspector 查看节点数据。如下：

从上图中可以看到DemoService 这个服务对应的配置信息最终被注册到了zookeeper节点下。搞懂了服务注册的本质，那么接下来我们就可以去阅读服务注册的代码了。

protected void doRegister(URL url) {
    try {
        // 通过 Zookeeper 客户端创建节点，节点路径由 toUrlPath 方法生成，路径格式如下:
        //   /${group}/${serviceInterface}/providers/${url}
        // 比如
        //   /dubbo/org.apache.dubbo.DemoService/providers/dubbo%3A%2F%2F127.0.0.1......
        zkClient.create(toUrlPath(url), url.getParameter(Constants.DYNAMIC_KEY, true));
    } catch (Throwable e) {
        throw new RpcException("Failed to register...");
    }
}

如上，ZookeeperRegistry 在 doRegister 中调用了 Zookeeper 客户端创建服务节点。节点路径由 toUrlPath 方法生成，该方法逻辑不难理解，就不分析了。接下来分析 create 方法，如下：

public void create(String path, boolean ephemeral) {
    if (!ephemeral) {
        // 如果要创建的节点类型非临时节点，那么这里要检测节点是否存在
        if (checkExists(path)) {
            return;
        }
    }
    int i = path.lastIndexOf('/');
    if (i > 0) {
        // 递归创建上一级路径
        create(path.substring(0, i), false);
    }
    
    // 根据 ephemeral 的值创建临时或持久节点
    if (ephemeral) {
        createEphemeral(path);
    } else {
        createPersistent(path);
    }
}

好了，到此关于服务注册的过程就分析完了。整个过程可简单总结为：先创建注册中心实例，之后再通过注册中心实例注册服务。

总结

在有注册中心，需要注册提供者地址的情况下，ServiceConfig 解析出的 URL 格式为：registry:// registry-host/org.apache.dubbo.registry.RegistryService?export=URL.encode("dubbo://service-host/{服务名}/{版本号}")
基于 Dubbo SPI 的自适应机制，通过 URL registry:// 协议头识别，就调用 RegistryProtocol#export() 方法
1. 将具体的服务类名，比如 DubboServiceRegistryImpl，通过 ProxyFactory 包装成 Invoker 实例
2. 调用 doLocalExport 方法，使用 DubboProtocol 将 Invoker 转化为 Exporter 实例，并打开 Netty 服务端监听客户请求
3. 创建 Registry 实例，连接 Zookeeper，并在服务节点下写入提供者的 URL 地址，注册服务
4. 向注册中心订阅 override 数据，并返回一个 Exporter 实例
根据 URL 格式中的 "dubbo://service-host/{服务名}/{版本号}"中协议头 dubbo:// 识别，调用 DubboProtocol#export() 方法，开发服务端口
RegistryProtocol#export() 返回的 Exporter 实例存放到 ServiceConfig 的 List<Exporter> exporters 中

服务发现

在学习了服务暴露原理之后，接下来重点探讨服务是如何消费的。这里主要讲解如何通过注册中心进行服务发现进行远程服务调用等细节。

服务发现流程

在详细探讨服务暴露细节之前，我们先看一下整体duubo的服务消费原理

在整体上看， Dubbo 框架做服务消费也分为两大部分，第一步通过持有远程服务实例生成Invoker, 这个 Invoker 在客户端是核心的远程代理对象。第二步会把 Invoker 通过动态代理转换成实现用户接口的动态代理引用。

服务消费方引用服务的蓝色初始化链，时序图如下：

源码分析

引用入口

服务引用的入口方法为 ReferenceBean 的 getObject 方法，该方法定义在 Spring 的 FactoryBean 接口中，ReferenceBean 实现了这个方法。

public Object getObject() throws Exception {
    return get();
}


public synchronized T get() {
    // 检测 ref 是否为空，为空则通过 init 方法创建
    if (ref == null) {
        // init 方法主要用于处理配置，以及调用 createProxy 生成代理类
        init();
    }
    return ref;
}

Dubbo 提供了丰富的配置，用于调整和优化框架行为，性能等。Dubbo 在引用或导出服务时，首先会对这些配置进行检查和处理，以保证配置的正确性。

private void init() {
    // 创建代理类
    ref = createProxy(map);
}

此方法代码很长，主要完成的配置加载，检查，以及创建引用的代理对象。这里要从 createProxy 开始看起。从字面意思上来看，createProxy 似乎只是用于创建代理对象的。但实际上并非如此，该方法还会调用其他方法构建以及合并 Invoker 实例。具体细节如下。

private T createProxy(Map<String, String> map) {
    URL tmpUrl = new URL("temp", "localhost", 0, map);
    ...........
    isDvmRefer = InjvmProtocol . getlnjvmProtocol( ) . islnjvmRefer(tmpUrl) 
    // 本地引用略
    if (isJvmRefer) {


    } else {
        // 点对点调用略
        if (url != null && url.length() > 0) {


            
        } else {
            // 加载注册中心 url
            List<URL> us = loadRegistries(false);
            if (us != null && !us.isEmpty()) {
                for (URL u : us) {
                    URL monitorUrl = loadMonitor(u);
                    if (monitorUrl != null) {
                        map.put(Constants.MONITOR_KEY, URL.encode(monitorUrl.toFullString()));
                    }
                    // 添加 refer 参数到 url 中，并将 url 添加到 urls 中
                    urls.add(u.addParameterAndEncoded(Constants.REFER_KEY, StringUtils.toQueryString(map)));
                }
            }
        }


        // 单个注册中心或服务提供者(服务直连，下同)
        if (urls.size() == 1) {
            // 调用 RegistryProtocol 的 refer 构建 Invoker 实例
            invoker = refprotocol.refer(interfaceClass, urls.get(0));
        // 多个注册中心或多个服务提供者，或者两者混合
        } else {
            List<Invoker<?>> invokers = new ArrayList<Invoker<?>>();
            URL registryURL = null;


            // 获取所有的 Invoker
            for (URL url : urls) {
                // 通过 refprotocol 调用 refer 构建 Invoker，refprotocol 会在运行时
                // 根据 url 协议头加载指定的 Protocol 实例，并调用实例的 refer 方法
                invokers.add(refprotocol.refer(interfaceClass, url));
                if (Constants.REGISTRY_PROTOCOL.equals(url.getProtocol())) {
                    registryURL = url;
                }
            }
            if (registryURL != null) {
                // 如果注册中心链接不为空，则将使用 AvailableCluster
                URL u = registryURL.addParameter(Constants.CLUSTER_KEY, AvailableCluster.NAME);
                // 创建 StaticDirectory 实例，并由 Cluster 对多个 Invoker 进行合并
                invoker = cluster.join(new StaticDirectory(u, invokers));
            } else {
                invoker = cluster.join(new StaticDirectory(invokers));
            }
        }
    }


    //省略无关代码


    // 真正根据invoker 生成代理类
    return (T) proxyFactory.getProxy(invoker);
}

上面代码很多，不过逻辑比较清晰。

1、如果是本地调用，直接jvm 协议从内存中获取实例

2、如果只有一个注册中心，直接通过 Protocol 自适应拓展类构建 Invoker 实例接口

3、如果有多个注册中心，此时先根据 url 构建 Invoker。然后再通过 Cluster 合并多个 Invoker，最后调用 ProxyFactory 生成代理类

创建客户端

在服务消费方，Invoker 用于执行远程调用。Invoker 是由 Protocol 实现类构建而来。Protocol 实现类有很多，这里分析DubboProtocol

1、在AbstractProtocol.refer调用protocolBindingRefer

@Override
    public <T> Invoker<T> refer(Class<T> type, URL url) throws RpcException {
        return new AsyncToSyncInvoker<>(protocolBindingRefer(type, url));
    }

查看DubboInvoker中的refer方法

public <T> Invoker<T> refer(Class<T> serviceType, URL url) throws RpcException {
    optimizeSerialization(url);
    // 创建 DubboInvoker
    DubboInvoker<T> invoker = new DubboInvoker<T>(serviceType, url, getClients(url), invokers);
    invokers.add(invoker);
    return invoker;
}

上面方法看起来比较简单，创建一个DubboInvoker。通过构造方法传入远程调用的client对象。默认情况下，Dubbo 使用 NettyClient 进行通信。接下来，我们简单看一下 getClients 方法的逻辑。

private ExchangeClient[] getClients(URL url) {
    // 是否共享连接
    boolean service_share_connect = false;
    // 获取连接数，默认为0，表示未配置
    int connections = url.getParameter(Constants.CONNECTIONS_KEY, 0);
    // 如果未配置 connections，则共享连接
    if (connections == 0) {
        service_share_connect = true;
        connections = 1;
    }


    ExchangeClient[] clients = new ExchangeClient[connections];
    for (int i = 0; i < clients.length; i++) {
        if (service_share_connect) {
            // 获取共享客户端
            clients[i] = getSharedClient(url);
        } else {
            // 初始化新的客户端
            clients[i] = initClient(url);
        }
    }
    return clients;
}

这里根据 connections 数量决定是获取共享客户端还是创建新的客户端实例，getSharedClient 方法中也会调用 initClient 方法，因此下面我们一起看一下这个方法。

private ExchangeClient initClient(URL url) {


    // 获取客户端类型，默认为 netty
    String str = url.getParameter(Constants.CLIENT_KEY, url.getParameter(Constants.SERVER_KEY, Constants.DEFAULT_REMOTING_CLIENT));
    
    //省略无关代码
    ExchangeClient client;
    try {
        // 获取 lazy 配置，并根据配置值决定创建的客户端类型
        if (url.getParameter(Constants.LAZY_CONNECT_KEY, false)) {
            // 创建懒加载 ExchangeClient 实例
            client = new LazyConnectExchangeClient(url, requestHandler);
        } else {
            // 创建普通 ExchangeClient 实例
            client = Exchangers.connect(url, requestHandler);
        }
    } catch (RemotingException e) {
        throw new RpcException("Fail to create remoting client for service...");
    }
    return client;
}

initClient 方法首先获取用户配置的客户端类型，默认为 netty。下面我们分析一下 Exchangers 的 connect 方法。

public static ExchangeClient connect(URL url, ExchangeHandler handler) throws RemotingException {
    // 获取 Exchanger 实例，默认为 HeaderExchangeClient
    return getExchanger(url).connect(url, handler);
}

如上，getExchanger 会通过 SPI 加载 HeaderExchangeClient 实例，这个方法比较简单，大家自己看一下吧。接下来分析 HeaderExchangeClient 的实现。

public ExchangeClient connect(URL url, ExchangeHandler handler) throws RemotingException {
    // 这里包含了多个调用，分别如下：
    // 1. 创建 HeaderExchangeHandler 对象
    // 2. 创建 DecodeHandler 对象
    // 3. 通过 Transporters 构建 Client 实例
    // 4. 创建 HeaderExchangeClient 对象
    return new HeaderExchangeClient(Transporters.connect(url, new DecodeHandler(new HeaderExchangeHandler(handler))), true);
}

这里的调用比较多，我们这里重点看一下 Transporters 的 connect 方法。如下：

public static Client connect(URL url, ChannelHandler... handlers) throws RemotingException {
    if (url == null) {
        throw new IllegalArgumentException("url == null");
    }
    ChannelHandler handler;
    if (handlers == null || handlers.length == 0) {
        handler = new ChannelHandlerAdapter();
    } else if (handlers.length == 1) {
        handler = handlers[0];
    } else {
        // 如果 handler 数量大于1，则创建一个 ChannelHandler 分发器
        handler = new ChannelHandlerDispatcher(handlers);
    }
    
    // 获取 Transporter 自适应拓展类，并调用 connect 方法生成 Client 实例
    return getTransporter().connect(url, handler);
}

如上，getTransporter 方法返回的是自适应拓展类，该类会在运行时根据客户端类型加载指定的 Transporter 实现类。若用户未配置客户端类型，则默认加载 NettyTransporter，并调用该类的 connect 方法。如下：

public Client connect(URL url, ChannelHandler listener) throws RemotingException {
    // 创建 NettyClient 对象
    return new NettyClient(url, listener);
}

注册

这里就已经创建好了NettyClient对象。关于 DubboProtocol 的 refer 方法就分析完了。接下来，继续分析 RegistryProtocol 的 refer 方法逻辑。

public <T> Invoker<T> refer(Class<T> type, URL url) throws RpcException {
    // 取 registry 参数值，并将其设置为协议头
    url = url.setProtocol(url.getParameter(Constants.REGISTRY_KEY, Constants.DEFAULT_REGISTRY)).removeParameter(Constants.REGISTRY_KEY);
    // 获取注册中心实例
    Registry registry = registryFactory.getRegistry(url);
    if (RegistryService.class.equals(type)) {
        return proxyFactory.getInvoker((T) registry, type, url);
    }


    // 将 url 查询字符串转为 Map
    Map<String, String> qs = StringUtils.parseQueryString(url.getParameterAndDecoded(Constants.REFER_KEY));
    // 获取 group 配置
    String group = qs.get(Constants.GROUP_KEY);
    if (group != null && group.length() > 0) {
        if ((Constants.COMMA_SPLIT_PATTERN.split(group)).length > 1
                || "*".equals(group)) {
            // 通过 SPI 加载 MergeableCluster 实例，并调用 doRefer 继续执行服务引用逻辑
            return doRefer(getMergeableCluster(), registry, type, url);
        }
    }
    
    // 调用 doRefer 继续执行服务引用逻辑
    return doRefer(cluster, registry, type, url);
}

上面代码首先为 url 设置协议头，然后根据 url 参数加载注册中心实例。然后获取 group 配置，根据 group 配置决定 doRefer 第一个参数的类型。这里的重点是 doRefer 方法，如下：

private <T> Invoker<T> doRefer(Cluster cluster, Registry registry, Class<T> type, URL url) {
    // 创建 RegistryDirectory 实例
    RegistryDirectory<T> directory = new RegistryDirectory<T>(type, url);
    // 设置注册中心和协议
    directory.setRegistry(registry);
    directory.setProtocol(protocol);
    Map<String, String> parameters = new HashMap<String, String>(directory.getUrl().getParameters());
    // 生成服务消费者链接
    URL subscribeUrl = new URL(Constants.CONSUMER_PROTOCOL, parameters.remove(Constants.REGISTER_IP_KEY), 0, type.getName(), parameters);


    // 注册服务消费者，在 consumers 目录下新节点
    if (!Constants.ANY_VALUE.equals(url.getServiceInterface())
            && url.getParameter(Constants.REGISTER_KEY, true)) {
        registry.register(subscribeUrl.addParameters(Constants.CATEGORY_KEY, Constants.CONSUMERS_CATEGORY,
                Constants.CHECK_KEY, String.valueOf(false)));
    }


    // 订阅 providers、configurators、routers 等节点数据
    directory.subscribe(subscribeUrl.addParameter(Constants.CATEGORY_KEY,
            Constants.PROVIDERS_CATEGORY
                    + "," + Constants.CONFIGURATORS_CATEGORY
                    + "," + Constants.ROUTERS_CATEGORY));


    // 一个注册中心可能有多个服务提供者，因此这里需要将多个服务提供者合并为一个
    Invoker invoker = cluster.join(directory);
    ProviderConsumerRegTable.registerConsumer(invoker, url, subscribeUrl, directory);
    return invoker;
}

如上，doRefer 方法创建一个 RegistryDirectory 实例，然后生成服务者消费者链接，并向注册中心进行注册。注册完毕后，紧接着订阅 providers、configurators、routers 等节点下的数据。完成订阅后，RegistryDirectory 会收到这几个节点下的子节点信息。由于一个服务可能部署在多台服务器上，这样就会在 providers 产生多个节点，这个时候就需要 Cluster 将多个服务节点合并为一个，并生成一个 Invoker。

创建代理对象

Invoker 创建完毕后，接下来要做的事情是为服务接口生成代理对象。有了代理对象，即可进行远程调用。代理对象生成的入口方法为 ProxyFactory 的 getProxy，接下来进行分析。

public <T> T getProxy(Invoker<T> invoker) throws RpcException {
    // 调用重载方法
    return getProxy(invoker, false);
}


public <T> T getProxy(Invoker<T> invoker, boolean generic) throws RpcException {
    Class<?>[] interfaces = null;
    // 获取接口列表
    String config = invoker.getUrl().getParameter("interfaces");
    if (config != null && config.length() > 0) {
        // 切分接口列表
        String[] types = Constants.COMMA_SPLIT_PATTERN.split(config);
        if (types != null && types.length > 0) {
            interfaces = new Class<?>[types.length + 2];
            // 设置服务接口类和 EchoService.class 到 interfaces 中
            interfaces[0] = invoker.getInterface();
            interfaces[1] = EchoService.class;
            for (int i = 0; i < types.length; i++) {
                // 加载接口类
                interfaces[i + 1] = ReflectUtils.forName(types[i]);
            }
        }
    }
    if (interfaces == null) {
        interfaces = new Class<?>[]{invoker.getInterface(), EchoService.class};
    }


    // 为 http 和 hessian 协议提供泛化调用支持，参考 pull request #1827
    if (!invoker.getInterface().equals(GenericService.class) && generic) {
        int len = interfaces.length;
        Class<?>[] temp = interfaces;
        // 创建新的 interfaces 数组
        interfaces = new Class<?>[len + 1];
        System.arraycopy(temp, 0, interfaces, 0, len);
        // 设置 GenericService.class 到数组中
        interfaces[len] = GenericService.class;
    }


    // 调用重载方法
    return getProxy(invoker, interfaces);
}


public abstract <T> T getProxy(Invoker<T> invoker, Class<?>[] types);

如上，上面大段代码都是用来获取 interfaces 数组的，我们继续往下看。getProxy(Invoker, Class<?>[]) 这个方法是一个抽象方法，下面我们到 JavassistProxyFactory 类中看一下该方法的实现代码。

public <T> T getProxy(Invoker<T> invoker, Class<?>[] interfaces) {
    // 生成 Proxy 子类（Proxy 是抽象类）。并调用 Proxy 子类的 newInstance 方法创建 Proxy 实例
    return (T) Proxy.getProxy(interfaces).newInstance(new InvokerInvocationHandler(invoker));
}

上面代码并不多，首先是通过 Proxy 的 getProxy 方法获取 Proxy 子类，然后创建 InvokerInvocationHandler 对象，并将该对象传给 newInstance 生成 Proxy 实例。InvokerInvocationHandler 实现 JDK 的 InvocationHandler 接口，具体的用途是拦截接口类调用。下面以 org.apache.dubbo.demo.DemoService 这个接口为例，来看一下该接口代理类代码大致是怎样的（忽略 EchoService 接口）。

package org.apache.dubbo.common.bytecode;


public class proxy0 implements org.apache.dubbo.demo.DemoService {


    public static java.lang.reflect.Method[] methods;


    private java.lang.reflect.InvocationHandler handler;


    public proxy0() {
    }


    public proxy0(java.lang.reflect.InvocationHandler arg0) {
        handler = $1;
    }


    public java.lang.String sayHello(java.lang.String arg0) {
        Object[] args = new Object[1];
        args[0] = ($w) $1;
        Object ret = handler.invoke(this, methods[0], args);
        return (java.lang.String) ret;
    }
}

好了，到这里代理类生成逻辑就分析完了。整个过程比较复杂，大家需要耐心看一下。

总结

从注册中心发现引用服务：在有注册中心，通过注册中心发现提供者地址的情况下，ReferenceConfig 解析出的 URL 格式为：registry://registry-host:/org.apache.registry.RegistryService?refer=URL.encode("conumer-host/com.foo.FooService?version=1.0.0")。
通过 URL 的registry://协议头识别，就会调用RegistryProtocol#refer()方法
1. 查询提供者 URL，如 dubbo://service-host/com.foo.FooService?version=1.0.0 ，来获取注册中心
2. 创建一个 RegistryDirectory 实例并设置注册中心和协议
3. 生成 conusmer 连接，在 consumer 目录下创建节点，向注册中心注册
4. 注册完毕后，订阅 providers，configurators，routers 等节点的数据
5. 通过 URL 的 dubbo:// 协议头识别，调用 DubboProtocol#refer() 方法，创建一个 ExchangeClient 客户端并返回 DubboInvoker 实例
由于一个服务可能会部署在多台服务器上，这样就会在 providers 产生多个节点，这样也就会得到多个 DubboInvoker 实例，就需要 RegistryProtocol 调用 Cluster 将多个服务提供者节点伪装成一个节点，并返回一个 Invoker
Invoker 创建完毕后，调用 ProxyFactory 为服务接口生成代理对象，返回提供者引用

流程讲解(通过xml形式)

Dubbo服务端

服务启动流程

服务端启动,Spring容器会去读取dubbo:开头的标签,比如dubbo:service标签。将实现类导出为一个服务
Spring会把dubbo:开头的标签交给org.apache.dubbo.config.spring.schema.DubboNamespaceHandler这个类解析,DubboNamespaceHandler会将不同的标签都加载为不同的类。

/**
 * 解析配置文件中<dubbo:xxx></dubbo:xxx> 相关的配置,并向容器中注册bean信息
 */
registerBeanDefinitionParser("application", new DubboBeanDefinitionParser(ApplicationConfig.class, true));
registerBeanDefinitionParser("module", new DubboBeanDefinitionParser(ModuleConfig.class, true));
registerBeanDefinitionParser("registry", new DubboBeanDefinitionParser(RegistryConfig.class, true));
registerBeanDefinitionParser("config-center", new DubboBeanDefinitionParser(ConfigCenterBean.class, true));
registerBeanDefinitionParser("metadata-report", new DubboBeanDefinitionParser(MetadataReportConfig.class, true));
registerBeanDefinitionParser("monitor", new DubboBeanDefinitionParser(MonitorConfig.class, true));
registerBeanDefinitionParser("metrics", new DubboBeanDefinitionParser(MetricsConfig.class, true));
registerBeanDefinitionParser("provider", new DubboBeanDefinitionParser(ProviderConfig.class, true));
registerBeanDefinitionParser("consumer", new DubboBeanDefinitionParser(ConsumerConfig.class, true));
registerBeanDefinitionParser("protocol", new DubboBeanDefinitionParser(ProtocolConfig.class, true));
registerBeanDefinitionParser("service", new DubboBeanDefinitionParser(ServiceBean.class, true));
registerBeanDefinitionParser("reference", new DubboBeanDefinitionParser(ReferenceBean.class, false));
registerBeanDefinitionParser("annotation", new AnnotationBeanDefinitionParser());

service标签会被解析称为一个ServiceBean

ServiceBean会实现Spring的ApplicationListener，在容器初识初始化完成后，会回调一个事件方法onApplicationEvent，这个方法会真正去导出服务(后面会具体分析服务导导出逻辑)
onApplicationEvent会去执行服务导出。服务导出分为两个过程：1. 通过协议Protocol导出服务为一个Invoker(默认的协议为Doubbo) 2. 通过Registry将导出的服务注册到注册中心
导出后的Expoter会全部保存到exporterMap中，<serviceKey，Exporter>的形式。

接收请求流程

xxxxxxxxxx
NettyServerHandler#channelRead(ChannelHandlerContext, MessageEvent)
  —> AbstractPeer#received(Channel, Object)
    —> MultiMessageHandler#received(Channel, Object)
      —> HeartbeatHandler#received(Channel, Object)
        —> AllChannelHandler#received(Channel, Object)
          —> ExecutorService#execute(Runnable)    // 由线程池执行后续的调用逻辑 ChannelEventRunnable

解码器ExchangeCodec:调用decode方法完成对Request对象的一次解码。
反序列化解码器DubboCodec:调用decodeBody方法完成对Request对象的二次解码
读事件:NettyServerHanlder的channelRead会读取到解码后的Request对象
线程模型:默认为AllChannelHandler,具体的会在Netty线程模型的时候详细讲解。AllChannelHandler会将所有消息都派发到线程池中处理，所以读事件也会交给线程池。
线程池中的线程:最终会调用到线程池中ChannelEventRunnable线程的run方法,它的run方法中不包含具体的调用逻辑。只是一个中转站，仅用于将参数传给具体的业务handler处理。此时为DecodeHandler。
DecodeHandler:包含了一些解码逻辑，比如对Request的Data的解码，对Response的result字段进行解码。然后向后传递!
协议Protocol:默认是DubboProtocol，会从exporterMap查找与serviceKey相对应的DubboExporter对象。执行doInvoke方法获取响应结果，并将结果封装到RpcResult中。
代理工厂:默认是JavassistProxyFactory，doInvoke方法是一个抽象方法。具体的会交给JavassistProxyFactory运行时生成的代理类执行。
到此，请求接收完毕。已经获取到响应经过，准备发送响应给客户端。

发送响应流程

编码器ExchangeCodec:会将响应结果RpcResult封装成Response对象，并对响应对象进行编码
其余逻辑和客户端发送请求逻辑相似(略)

客户端

服务启动流程

和服务端一样，DubboNamespaceHandler会将Reference解析为一个ReferenceBean。
ReferenceBean会实现FactoryBean接口，FactoryBean接口会返回一个具体的Bean注入到容器中。这个返回具体的Bean就是代理的服务端可执行的具体Invoker，这个Invoker是一个Cluster集群。后面会具体讲解Cluster组件！

向服务端发送请求流程

调用链路

proxy0#sayHello(String)
  —> InvokerInvocationHandler#invoke(Object, Method, Object[])
    —> MockClusterInvoker#invoke(Invocation)
      —> AbstractClusterInvoker#invoke(Invocation)
        —> FailoverClusterInvoker#doInvoke(Invocation, List<Invoker<T>>, LoadBalance)
          —> Filter#invoke(Invoker, Invocation)  // 包含多个 Filter 调用
            —> ListenerInvokerWrapper#invoke(Invocation) 
              —> AbstractInvoker#invoke(Invocation) 
                —> DubboInvoker#doInvoke(Invocation)
                  —> ReferenceCountExchangeClient#request(Object, int)
                    —> HeaderExchangeClient#request(Object, int)
                      —> HeaderExchangeChannel#request(Object, int)
                        —> AbstractPeer#send(Object)
                          —> AbstractClient#send(Object, boolean)
                            —> NettyChannel#send(Object, boolean)
                              —> NioClientSocketChannel#write(Object)

InvokerInvocationHandler:这个是在客户端启动的时候生成的代理拦截类。将代理对象，代理方法和代理方法的参数传入下一层！
服务降级的Invoker:InvokerInvocationHandler内部包装了服务降级的MockClusterInvoker，MockClusterInvoker内部封装了服务降级的逻辑：1.如果没有mock逻辑，直接调用Invoker的invoke方法。2. 如果mock为force，直接执行mock逻辑，不发起远程调用。3.如果mock为fail，先通过Invoker调用服务，如果调用失败。再执行mock逻辑。将代理对象，代理方法，代理方法的参数封装为一个Invocation传入下一层。
集群容错的Invoker:MockClusterInvoker内部包装了集群容错的FailoverClusterInvoker，FailoverClusterInvoker是集群容错的默认策略。默认失败后重试2次，具体集群容错策略详见集群容错分析。MockClusterInvoker将代理的Invocation，服务提供者invokers(可能会有多个),负载均衡策略传入下一层。
Filter过滤器:很多个Filter后最终会通过负载均衡策略选出一个具体的Invoker。
具体协议的Invoker:DubboInvoker的doInvoke方法会将去获取客户端连接，真正发送请求获取结果。
ExchangeInvoker:HeaderExchangeChannel会将请求拼装Request请求并发送出去
编码器ExhcangeCodec:调用encode方法完成编码工作。ExchangeCodec会使用Dubbo协议，通过位运算将请求头写入到header数组中。然后对Request对象的data进行序列化工作，得到data的长度，将len写入到header的自定位置。
序列化操作DubboCodec:调用encodeRequestData方法完成对Request对象的具体序列化操作，默认采用Hessian进行序列化操作。
到此，服务消费方的请求过程就已经完成了。

接收服务端请求流程

ExchangeCodec：将服务端发送的Response数据进行解码
NettyClientHandler:解码完成后会进入到NettyClientHandler，具体操作交给后续的handler
AllChannelHandler：所有的请求都会交给线程池
ChannelEventRunnable：由线程池中的线程进行处理
HeaderExchangeHandler：线程池中的线程最终会及交给HeaderExchangeHandler的received方法处理响应。
DefaultFuture：交给future进行唤醒，并设置异步返回的结果。
InvokerInvocationHandler：最后会将结果交给过代理生成的方法处理。

补充

异步转同步

Dubbo发送数据至服务方后，在通信层面是异步的，通信线程并不会等待结果数据返回。而我们在使用Dubbo进行RPC调用缺省就是同步的，这其中就涉及到了异步转同步的操作。

2.7.x版本中，这种自实现的异步转同步操作进行了修改。新的DefaultFuture继承了CompletableFuture。
过CompletableFuture#complete方法来设置异步的返回结果，且删除旧的get()方法，使用CompletableFuture#get()方法。

异步多线程数据一致

心跳检查

bbo采用双向心跳的方式检测Client端与Server端的连通性。
Dubbo 的心跳是双向心跳，客户端会给服务端发送心跳，反之，服务端也会向客户端发送心跳。

创建定时器

Dubbo 在 HeaderExchangeClient初始化时开启了两个定时任务

startReconnectTask 主要用于定时发送心跳请求
startHeartBeatTask 主要用于心跳失败之后处理重连，断连的逻辑

发送心跳请求

详细解析下心跳检测定时任务的逻辑 HeartbeatTimerTask#doTask：前面已经介绍过，Dubbo 采取的是双向心跳设计，即服务端会向客户端发送心跳，客户端也会向服务端发送心跳，接收的一方更新 lastRead 字段，发送的一方更新 lastWrite 字段，超过心跳间隙的时间，便发送心跳请求给对端。这里的 lastRead/lastWrite 同样会被同一个通道上的普通调用更新，通过更新这两个字段，实现了只在连接空闲时才会真正发送空闲报文的机制，符合我们一开始科普的做法。

处理重连和断连

第二个定时器则负责根据客户端、服务端类型来对连接做不同的处理，当超过设置的心跳总时间之后，客户端选择的是重新连接，服务端则是选择直接断开连接。这样的考虑是合理的，客户端调用是强依赖可用连接的，而服务端可以等待客户端重新建立连接。
Dubbo 对于建立的每一个连接，同时在客户端和服务端开启了 2 个定时器，一个用于定时发送心跳，一个用于定时重连、断连，执行的频率均为各自检测周期的 1/3。定时发送心跳的任务负责在连接空闲时，向对端发送心跳包。定时重连、断连的任务负责检测 lastRead 是否在超时周期内仍未被更新，如果判定为超时，客户端处理的逻辑是重连，服务端则采取断连的措施。

源码讲解

框架设计

整体设计

各层说明

config 配置层：对外配置接口，以 ServiceConfig, ReferenceConfig 为中心，可以直接初始化配置类，也可以通过 spring 解析配置生成配置类
proxy 服务代理层：服务接口透明代理，生成服务的客户端 Stub 和服务器端 Skeleton, 以 ServiceProxy 为中心，扩展接口为 ProxyFactory
registry 注册中心层：封装服务地址的注册与发现，以服务 URL 为中心，扩展接口为 RegistryFactory, Registry, RegistryService
cluster 路由层：封装多个提供者的路由及负载均衡，并桥接注册中心，以 Invoker 为中心，扩展接口为 Cluster, Directory, Router, LoadBalance
monitor 监控层：RPC 调用次数和调用时间监控，以 Statistics 为中心，扩展接口为 MonitorFactory, Monitor, MonitorService
protocol 远程调用层：封装 RPC 调用，以 Invocation, Result 为中心，扩展接口为 Protocol, Invoker, Exporter
exchange 信息交换层：封装请求响应模式，同步转异步，以 Request, Response 为中心，扩展接口为 Exchanger, ExchangeChannel, ExchangeClient, ExchangeServer
transport 网络传输层：抽象 mina 和 netty 为统一接口，以 Message 为中心，扩展接口为 Channel, Transporter, Client, Server, Codec
serialize 数据序列化层：可复用的一些工具，扩展接口为 Serialization, ObjectInput, ObjectOutput, ThreadPool

关系说明

在 RPC 中，Protocol 是核心层，也就是只要有 Protocol + Invoker + Exporter 就可以完成非透明的 RPC 调用，然后在 Invoker 的主过程上 Filter 拦截点。
而 Cluster 是外围概念，所以 Cluster 的目的是将多个 Invoker 伪装成一个 Invoker，这样其它人只要关注 Protocol 层 Invoker 即可，加上 Cluster 或者去掉 Cluster 对其它层都不会造成影响，因为只有一个提供者时，是不需要 Cluster 的。
Proxy 层封装了所有接口的透明化代理，而在其它层都以 Invoker 为中心，只有到了暴露给用户使用时，才用 Proxy 将 Invoker 转成接口，或将接口实现转成 Invoker，也就是去掉 Proxy 层 RPC 是可以 Run 的，只是不那么透明，不那么看起来像调本地服务一样调远程服务。
而 Remoting 实现是 Dubbo 协议的实现，如果你选择 RMI 协议，整个 Remoting 都不会用上，Remoting 内部再划为 Transport 传输层和 Exchange 信息交换层，Transport 层只负责单向消息传输，是对 Mina, Netty, Grizzly 的抽象，它也可以扩展 UDP 传输，而 Exchange 层是在传输层之上封装了 Request-Response 语义。
Registry 和 Monitor 实际上不算一层，而是一个独立的节点，只是为了全局概览，用层的方式画在一起。

模块分包

dubbo-common 公共逻辑模块：包括 Util 类和通用模型。
dubbo-remoting 远程通讯模块：相当于 Dubbo 协议的实现，如果 RPC 用 RMI协议则不需要使用此包。
dubbo-rpc 远程调用模块：抽象各种协议，以及动态代理，只包含一对一的调用，不关心集群的管理。
dubbo-cluster 集群模块：将多个服务提供方伪装为一个提供方，包括：负载均衡, 容错，路由等，集群的地址列表可以是静态配置的，也可以是由注册中心下发。
dubbo-registry 注册中心模块：基于注册中心下发地址的集群方式，以及对各种注册中心的抽象。
dubbo-monitor 监控模块：统计服务调用次数，调用时间的，调用链跟踪的服务。
dubbo-config 配置模块：是 Dubbo 对外的 API，用户通过 Config 使用Dubbo，隐藏 Dubbo 所有细节。
dubbo-container 容器模块：是一个 Standlone 的容器，以简单的 Main 加载 Spring 启动，因为服务通常不需要 Tomcat/JBoss 等 Web 容器的特性，没必要用 Web 容器去加载服务。

整体上按照分层结构进行分包，与分层的不同点在于：

container 为服务容器，用于部署运行服务，没有在层中画出。
protocol 层和 proxy 层都放在 rpc 模块中，这两层是 rpc 的核心，在不需要集群也就是只有一个提供者时，可以只使用这两层完成 rpc 调用。
transport 层和 exchange 层都放在 remoting 模块中，为 rpc 调用的通讯基础。
serialize 层放在 common 模块中，以便更大程度复用。

Dubbo的高可用集群

组件介绍

Directory：它代表多个Invoker，从methodInvokerMap提取，但是他的值是动态，例如注册中心的变更。
Router：负责从多个Invoker中按路由规则选出子集，例如应用隔离或读写分离或灰度发布等等
Cluster：将Directory中的多个Invoker伪装成一个Invoker,来容错，调用失败重试。
LoadBalance：从多个Invoker选取一个做本次调用，具体包含很多种负载均衡算法。
Invoker：Provider中的一个可调用接口。例如DemoService

集群负载均衡策略

内置的负载均衡策略

Random LoadBalance 随机，按权重设置随机概率。 Dubbo的默认负载均衡策略
RoundRobin LoadBalance 轮循，按公约后的权重设置轮循比率。
LeastActive LoadBalance 最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差。
ConsistentHash LoadBalance 一致性Hash，相同参数的请求总是发到同一提供者。

集群容错机制

内置集群容错策略

Dubbo默认内置了若干容错策略，如果不能满足用户需求，则可以通过自定义容错策略进行配置 Dubbo主要内置了如下几种策略：

Failover(失败自动切换)
Failsafe(失败安全)
Failfast(快速失败)
Failback(失败自动恢复)
Forking(并行调用)
Broadcast(广播调用) 默认为Failover

配置方式

接口级别

<dubbo:service interface="org.apache.dubbo.demo.DemoService" ref="demoService" cluster="failover" retries="2" />

方法级别

<dubbo:service interface="org.apache.dubbo.demo.DemoService" ref="demoService"cluster="failover">
     <dubbo:method name="sayHello" retries="2" />
 </dubbo:service>

这是在服务端配置，消费端一样。建议在消费端进行配置，在服务端进行配置也是同步到客户端进行。而且客户端的优先级高于服务端。

几种策略比较

策略名称	优点	缺点
Failover	对调用者屏蔽调用失败的信息	增加RT，额外资源开销，资源浪费
Failfast	业务快速感知失败状态进行自主决策	产生较多报错的信息
Failsafe	即使失败了也不会影响核心流程	对于失败的信息不敏感，需要额外的监控
Failback	失败自动异步重试	重试任务可能堆积
Forking	并行发起多个调用，降低失败概率	消耗额外的机器资源，需要确保操作幂等性
Broadcast	支持对所有的服务提供者进行操作	资源消耗很大

Failover ：通常用于对调用retry不敏感的场景，如读操作；但重试会带来更长延迟
Failfast ：通常用于非幂等性操作，需要快速感知失败的场景；比如新增记录
Failsafe ：通常用于旁路系统，失败不影响核心流程正确性的场景；如日志记录
Failback ：通常用于对于实时性要求不高，且不需要返回值的一些异步操作的场景
Forking ：通常用于资源充足，且对于失败的容忍度较低，实时性要求高的读操作，但需要浪费更多服务资源
Broadcast：如通知所有提供者更新缓存或日志等本地资源信息

线程模型

配置 Dubbo 中的线程模型

如果事件处理的逻辑能迅速完成，并且不会发起新的 IO 请求，比如只是在内存中记个标识，则直接在 IO 线程上处理更快，因为减少了线程池调度。
但如果事件处理逻辑较慢，或者需要发起新的 IO 请求，比如需要查询数据库，则必须派发到线程池，否则 IO 线程阻塞，将导致不能接收其它请求。
如果用 IO 线程处理事件，又在事件处理过程中发起新的 IO 请求，比如在连接事件中发起登录请求，会报“可能引发死锁”异常，但不会真死锁。

<dubbo:protocol name="dubbo" dispatcher="all" threadpool="fixed" threads="100" />

Dispatcher

all:所有消息都派发到线程池，包括请求，响应，连接事件，断开事件，心跳等。
direct:所有消息都不派发到线程池，全部在 IO 线程上直接执行。
message:只有请求响应消息派发到线程池，其它连接断开事件，心跳等消息，直接在 IO 线程上执行。
execution:只有请求消息派发到线程池，不含响应，响应和其它连接断开事件，心跳等消息，直接在 IO 线程上执行。
connection:在 IO 线程上，将连接断开事件放入队列，有序逐个执行，其它消息派发到线程池。

ThreadPool

fixed:固定大小线程池，启动时建立线程，不关闭，一直持有。(缺省)
cached:缓存线程池，空闲一分钟自动删除，需要时重建。
limited:可伸缩线程池，但池中的线程数只会增长不会收缩。只增长不收缩的目的是为了避免收缩时突然来了大流量引起的性能问题。
eager:优先创建Worker线程池。在任务数量大于corePoolSize但是小于maximumPoolSize时，优先创建Worker来处理任务。当任务数量大于maximumPoolSize时，将任务放入阻塞队列中。阻塞队列充满时抛出RejectedExecutionException。(相比于cached:cached在任务数量超过maximumPoolSize时直接抛出异常而不是将任务放入阻塞队列)

Dubbo源码分析

SPI机制

SPI的概述

SPI的主要作用

入门案例

总结

Dubbo中的SPI

概述

入门案例

源码分析

SPI中的IOC和AOP

依赖注入

动态增强

动态编译

SPI中的自适应

javassist入门

源码分析

服务暴露(导出)与发现

概述

Spring中自定义Schema

案例使用

dubbo中的相关对象

服务暴露机制

术语解释

流程机制

源码分析

导出入口

导出服务到本地

导出服务到远程(重点)

开启Netty服务

服务注册

总结

服务发现

服务发现流程

源码分析

引用入口

创建客户端

注册

创建代理对象

总结

流程讲解(通过xml形式)

Dubbo服务端

服务启动流程

接收请求流程

发送响应流程

客户端

服务启动流程

向服务端发送请求流程

接收服务端请求流程

补充

异步转同步

异步多线程数据一致

心跳检查

创建定时器

发送心跳请求

处理重连和断连

源码讲解

框架设计

整体设计

各层说明

关系说明

模块分包

Dubbo的高可用集群

组件介绍

集群负载均衡策略

内置的负载均衡策略

集群容错机制

内置集群容错策略

配置方式

几种策略比较

线程模型