本篇主要介绍 Dubbo 服务导出的实现细节。

定义服务接口 HelloWorld：

public interface HelloWorld {
    String sayHello();
}

服务实现类 HelloWorldImpl：

public class HelloWorldImpl implements HelloWorld {
    @Override
    public String sayHello() {

        return "Hello wlm..";
    }
}

服务导出的配置：

<?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:dubbo="http://dubbo.apache.org/schema/dubbo"
    xsi:schemaLocation="http://www.springframework.org/schema/beans        
        http://www.springframework.org/schema/beans/spring-beans-4.3.xsd        
        http://dubbo.apache.org/schema/dubbo        
        http://dubbo.apache.org/schema/dubbo/dubbo.xsd">
 
    <!-- 提供方应用信息，用于计算依赖关系 -->
    <dubbo:application name="hello-world-app"  />
 
    <!-- 使用 zookeeper 注册中心暴露服务地址 -->
    <dubbo:registry protocol="zookeeper" address="127.0.0.1:2181"/>
 
    <!-- 用dubbo协议在20880端口暴露服务 -->
    <dubbo:protocol name="dubbo" port="20880" />

    <bean id="helloWorldImpl" class="com.wlm.dubbo.service.HelloWorldImpl" />
    <dubbo:service interface="com.wlm.dubbo.service.HelloWorld" ref="helloWorldImpl" version="1.0"/>
    
</beans>

以 Spring 方式启动服务：

public class DubboStarter {
    public static void main(String[] args) throws InterruptedException {
        ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext(new String[]{"classpath*:META-INF/spring/dubbo-start.xml"}, true);
        context.start();
    }
}

解析 bean 属性

以 Spring 作为容器启动服务时，会先解析 bean 的属性。Spring 的 bean 属性解析分为默认标签和自定义标签两种，其中自定义标签的解析需要实现 NamespaceHandler 接口，Dubbo 的标签 dubbo 即为自定义标签。

Dubbo 定义解析标签的实现类为 DubboNamespaceHandler：

image.png

这里面定义了 Dubbo 支持的各种标签，比如：application，registry，service，reference 等。

可以看到，dubbo 的 bean 属性都通过 DubboBeanDefinitionParser 解析成 BeanDefinition 对象，同时构造函数会传入最终实例化的 beanClass，比如 service 标签对应 ServiceBean，reference 标签对应 ReferenceBean。具体的实现不是本文的重点，这里就不展开。

服务导出入口

根据前面的说明，服务提供者相关的属性最终会实例化成 ServiceBean 对象，该对象监听了 Spring 的上下文刷新事件 ContextRefreshedEvent，会在 Spring 完成上下文刷新，也就是 bean 完成初始化之后被通知：

@Override
public void onApplicationEvent(ContextRefreshedEvent event) {
    if (!isExported() && !isUnexported()) {
        if (logger.isInfoEnabled()) {
            logger.info("The service ready on spring started. service: " + getInterface());
        }
        export();
    }
}

Dubbo 就是在这里开启服务导出流程，并且在完成服务导出之后，发布服务导出事件 ServiceBeanExportedEvent：

public void export() {
    super.export();
    // Publish ServiceBeanExportedEvent
    publishExportEvent();
}

具体的导出逻辑由父类 ServiceConfig 实现：

image.png

Dubbo 通过 export 属性设置是否导出服务，通过 delay 属性设置延迟一定时间再导出服务。

接下来进入真正的服务导出流程：

image.png

分为两步：加载注册中心地址，遍历协议（ProtocolConfig）列表执行服务导出。

加载注册中心地址

通过 loadRegistries 方法加载注册中心地址，得到一个协议头为 registry 的 URL 列表：

image.png

入参表示是服务提供者还是消费者，先遍历 RegistryConfig 列表，将 address 属性解析成 URL 列表，格式如下：

zookeeper://127.0.0.1:2181/org.apache.dubbo.registry.RegistryService?application=wlm
&dubbo=2.0.2&pid=29043&release=2.7.3&timestamp=1578322585876

再将上面的 URL 的协议头转换为 registry，原有的协议头变为新的 URL 对象的 registry 属性，格式如下：

registry://127.0.0.1:2181/org.apache.dubbo.registry.RegistryService?application=wlm
&dubbo=2.0.2&pid=29043&registry=zookeeper&release=2.7.3&timestamp=1578322585876

服务导出

通过 doExportUrlsFor1Protocol 执行服务导出，这里重点关注 scope=remote (即导出服务到远程) 的场景：

image.png

核心逻辑分为两步：

1. 调用 ProxyFactory#getInvoker：将具体实现类转换为 invoker 对象；
2. 调用 Protocol#export：执行服务导出，得到 Exporter 对象。

创建 invoker 对象

Invoker 是 Dubbo 的实体域，是 Dubbo 的核心模型。

ProxyFactory 即代理工厂类，是一种动态代理，包含两个操作：

• getInvoker: 将实现类转换为 invoker 对象；
• getProxy: 创建远程服务的代理。

ProxyFactory 支持 SPI 扩展，默认的实现是 JavassistProxyFactory，依赖于 javassist 组件，创建实现类的代理 Wrapper 对象：

image.png

创建代理类 Wrapper 对象的方式为：先动态生成代理类的 java 代码，再编译代理类，并加载到类加载器中，最后反射创建代理类的实例对象。

最终生成的代理类结构如下：

image.png

此处不深究 javassist 的实现细节，展示生成的代理类方法 invokeMethod:

image.png

JavassistProxyFactory 获取到 Wrapper 实例对象后，再封装成 AbstractProxyInvoker 匿名对象返回，该对象会将 doInvoke 请求转发给 Wrapper 对象。

Protocol.export

接下来调用 Protocol.export 执行服务导出。

首先通过 Dubbo 自适应扩展机制获取 Protocol 对象：

private static final Protocol protocol = ExtensionLoader.getExtensionLoader(Protocol.class).getAdaptiveExtension();

在 Dubbo SPI 机制中存在一些包装类（类名以 Wrapper 结尾，构造函数参数为当前接口的实现类），而此处 Protocol 的实现类中也存在包装类，因此最终得到的是一个 Protocol 链：

image.png

协议链最后一个节点是 RegistryProtocol，是因为协议头为 "registry"，RegistryProtocol 内部还有个 protocol 对象，也是通过 Dubbo SPI 机制获取，也对应着一个 Protocol 调用链，前面配置的协议为 "dubbo"：

image.png

整体的流程图如下：

image.png

主要分为以下几个部分：

1. 启动 qos server；
2. 构建服务提供者的 Filter 链；
3. 真正的服务导出；
4. 发布服务导出事件；
5. 注册服务地址；
6. 订阅

其中 1 在 QosProtocolWrapper 类，2 在 ProtocolFilterWrapper 类，3 在 DubboProtocol 类，4 在 ProtocolListenerWrapper 类，5、6 在 RegistryProtocol 类。

1.启动 qos server

qos 依赖于 netty，先从 URL 获取 qos 监听端口信息，再启动 qos server：

image.png

启动 qos server 时，重点关注两个操作：注册解码器 QosProcessHandler 和监听 qos 端口，其中解码器负责把 netty 接收到的字节流转换成对应业务所需要的格式：

image.png

2.构建 filter 链

构建逻辑如下：

image.png

构建 filter 链时需要指定三个参数：

• invoker：当前 invoker，形成 filter 链的最后一个节点；
• key：指定扩展点名称，多个以逗号分隔，从 URL 获取，服务提供者对应 "service.filter"，消费者对应 "reference.filter"；
• group：扩展点所属分组，提供者和消费者对应 provider 和 consumer。

构建 filter 链主要分为以下三个步骤：

1. 通过 Dubbo SPI 机制获取 filter 列表；
2. 将 filter 列表转换为 invoker 调用链；
3. 将 invoker 调用链封装为支持回调的 invoker 返回；

第1步获取 filter 链使用了 @Activate 注解：

public @interface Activate {
    /**
     * 匹配规则：分组
     */
    String[] group() default {};

    /**
     * 匹配规则：如果 URL 中出现 value 指定的 key，则返回当前扩展实现类
     */
    String[] value() default {};

    /**
     * 从小到大排序，可选
     */
    int order() default 0;
}

Dubbo 获取的扩展实现类由两部分组成：

• 有 @Activate 注解的类：遍历实现类列表，获取与指定的 group、value 匹配的实现类，并排序；
• 入参指定的扩展类名称，即入参 key，根据该名称获取扩展实现类，并加到 filter 列表最后。

第2步将调用 filter 封装成 invoker 实现类，上一个创建的 invoker 都是下一个 filter.invoke 入参，因此 Dubbo 是倒序遍历 filter 列表，这样第一个 filter 就是 invoker 调用链的第一个节点。

第3步将 invoker 调用链封装为 CallbackRegistrationInvoker 对象，在调用完 filter 之后，调用回调接口：

image.png

3.真正的服务导出

在 RegistryProtocol 内部，调用了真正的服务导出逻辑：

image.png

在 doLocalExport 内部，调用 Protocol.export 导出服务：

image.png

这里配置的是 "dubbo"，即 DubboProtocol，也就是前面介绍的第二个 Protocol 调用链。

整体服务导出的时序图如下：

image.png

上述 Exchanger、Transporter、Server 都支持 SPI 扩展。

概念解释：
1.Exchanger：信息交换层，封装请求响应模式，以 Request、Response 为中心，在 Transporter 层基础之上，默认实现为 HeaderExchanger；

客户端与服务端之间的消息发送模式（即 Message Exchange Pattern）有三种：

• 数据报(Datagram)：客户端发送消息后，服务端不会进行回复，比如电视新闻只管发布消息；
• 请求响应(Request/Response)：客户端发送消息后，会等待服务端的回复，比如在街上问路时的一问一答。这也是最常用的消息交换模式；
• 双工(Duplex)：客户端和服务端可以任意的发送消息，客户端和服务端变成通信的两个端点，比如两个人通话时可以同时说话；

Dubbo 的 Exchanger 使用的就是 "请求响应" 消息发送模式，包含了请求和响应两次网络传输。

2.Transporter：网络传输层，只有单次网络传输，两端对应 Client 和 Server，以 Message 为中心，默认实现为 NettyTransporter；

3.Server：即服务提供者，与之对应，Client 为服务消费者，默认实现为 NettyServer。

监听服务端口的过程中，这些组件都会被创建并初始化。

NettyServer 在初始化时会启动对服务端口的监听：

image.png

这里要注意的是，Dubbo 在 initChannel 时注册了自定义的编解码器 NettyCodecAdapter，这部分在服务调用时再介绍。

4.发布服务导出事件

ProtocolListenerWrapper 调用完 export 后，会返回 ListenerExporterWrapper 包装类，通过 Dubbo SPI 获取监听器（由用户自定义实现）ExporterLIstener 列表：

image.png

并在对象构造器内调用 ExporterListener.exported() 发布服务导出事件：

image.png

5.注册服务地址

RegistryProtocol 内部逻辑如下：

image.png

先生成注册中心 URL 信息 registryUrl 和服务提供方 URL 信息 providerUrl，如下所示：

// registry url
zookeeper://127.0.0.1:2181/org.apache.dubbo.registry.RegistryService?application=wlm
&dubbo=2.0.2&export=dubbo%3A%2F%2F192.168.199.243%3A20880%2Fcom.wlm.dubbo.service
.HelloWorld%3Fanyhost%3Dtrue%26application%3Dwlm%26bean.name%3Dcom.wlm.dubbo.service.
HelloWorld%26bind.ip%3D192.168.199.243%26bind.port%3D20880%26deprecated%3Dfalse%26
dubbo%3D2.0.2%26dynamic%3Dtrue%26generic%3Dfalse%26interface%3Dcom.wlm.dubbo.service
.HelloWorld%26methods%3DsayHello%26pid%3D40140%26register%3Dtrue%26release%3D2.7.3%26
revision%3D1.0%26service.filter%3DdubboFilter%26side%3Dprovider%26timestamp%3D1578403901317%26
version%3D1.0&pid=40140&release=2.7.3&timestamp=1578403901308

// provider url
dubbo://192.168.199.243:20880/com.wlm.dubbo.service.HelloWorld?anyhost=true
&application=wlm&bean.name=com.wlm.dubbo.service.HelloWorld&bind.ip=192.168.199.243
&bind.port=20880&deprecated=false&dubbo=2.0.2&dynamic=true&generic=false
&interface=com.wlm.dubbo.service.HelloWorld&methods=sayHello&pid=40140&register=true
&release=2.7.3&revision=1.0&service.filter=dubboFilter&side=provider
&timestamp=1578403901317&version=1.0

provider url 就是 registry url 中的 export 属性对应的值。

注册服务地址的逻辑如下：

public void register(URL registryUrl, URL registeredProviderUrl) {
    // 通过注册中心工厂获取注册中心
    Registry registry = registryFactory.getRegistry(registryUrl);
    // 注册服务地址
    registry.register(registeredProviderUrl);
}

先从 RegistryFactory 工厂获取注册中心 Registry 对象，再调用 Registry.register 将服务地址注册到注册中心。这两个接口都支持 SPI 扩展，zookeeper 注册中心分别对应着 ZookeeperRegistryFactory、ZookeeperRegistry。

往 zookeeper 注册中心注册服务地址，即创建目录节点：

public void doRegister(URL url) {
    try {
        zkClient.create(toUrlPath(url), url.getParameter(DYNAMIC_KEY, true));
    } catch (Throwable e) {
        throw new RpcException("Failed to register " + url + " to zookeeper " + getUrl() + ", cause: " + e.getMessage(), e);
    }
}

最终服务地址注册到 zookeeper 路径：/dubbo/com.wlm.dubbo.service.HelloWorld/providers/，内容如下：

image.png

6.订阅

服务订阅 URL 在服务提供方 URL 基础上，将 protocol 设置为 "provider"，并且添加了 "category" 属性，生成 overrideSubscribeUrl 为：

provider://192.168.199.243:20880/com.wlm.dubbo.service.HelloWorld?anyhost=true
&application=wlm&bean.name=com.wlm.dubbo.service.HelloWorld&bind.ip=192.168.199.243
&bind.port=20880&category=configurators&check=false&deprecated=false&dubbo=2.0.2
&dynamic=true&generic=false&interface=com.wlm.dubbo.service.HelloWorld
&methods=sayHello&pid=39668&register=true&release=2.7.3&revision=1.0
&service.filter=dubboFilter&side=provider&timestamp=1578401531082&version=1.0

接着调用 ZookeeperRegistry.subscribe 进行订阅，入参为 overrideSubscribeUrl 和 OverrideListener 对象，OverrideListener 是个监听器，是 NotifyListener 的子类，订阅的数据发生变化时会被通知。

ZookeeperRegistry 内部根据 interface 是否配置为 * 分为两种逻辑，我们重点关注指定了 interface 的场景：

image.png

先调用 toCategoriesPath，将 overrideSubscribeUrl 转换为 category 目录列表，这里只有 configurators：

/dubbo/com.wlm.dubbo.service.HelloWorld/configurators

再遍历该列表，执行以下逻辑：

1. 创建监听器 ChildListener，内部调用入参传递的 NotifyListener；
2. 创建 category 目录节点；
3. 将 ChildListener 注册到 zookeeper，得到子节点信息 children；
4. 调用 toUrlsWithEmpty 将 overrideSubscribeUrl、path、children 信息转换成新的 provider URL。

得到的新 provider URL 格式如下：

empty://192.168.199.243:20880/com.wlm.dubbo.service.HelloWorld?anyhost=true
&application=wlm&bean.name=com.wlm.dubbo.service.HelloWorld&bind.ip=192.168.199.243
&bind.port=20880&category=configurators&check=false&deprecated=false&dubbo=2.0.2
&dynamic=true&generic=false&interface=com.wlm.dubbo.service.HelloWorld&methods=sayHello
&pid=40629&register=true&release=2.7.3&revision=1.0&service.filter=dubboFilter
&side=provider&timestamp=1578406499862&version=1.0

最后主动触发一下 notify。

总结

本篇文章侧重于 Dubbo 服务导出的实现细节，主要包括：服务导出入口，加载注册中心地址，创建 invoker 对象，启动 qos server，构建 filter 链，服务导出，发布服务导出事件，注册服务地址，订阅等。其中省略了很多细节，比如 Dubbo 的 bean 属性配置如何解析，并最终得到 URL 等，限于篇幅，读者可自行查看。