在前面的文章中我主要说明了以下几个问题：

1. Spring启动的时候如何扫描到DubboService注解，并加入容器中的。

主要是通过ServiceClassPostProcessor这个核心类来实现的

2. Spring如何将容器中的对象注入DubboReference注解的字段中的。

主要是通过这个核心类ReferenceAnnotationBeanPostProcessor类来实现的. 实现机制和Spring的Autowired注解的机制一样的

3. dubbo的启动过程 会做哪些操作

可以看下我的 Dubbo的启动过程源码分析 – 初始化过程（4） , 这篇值是单独的介绍Dubbo的启动过程， 并没有说明和Spring结合是如何启动的。

在这篇博客中我会说明和Spring整合后，dubbo是如何启动的，如何暴露服务的。

Dubbo监听Spring启动完成事件

在spring的框架启动完成后会发出一个事件， 而Dubbo就注册了这个事件的监听器DubboBootstrapApplicationListener, 这个是在ServiceClassPostProcessor类的postProcessBeanDefinitionRegistry方法中第一行注册的。

DubboBootstrapApplicationListener中处理事件的方式就是调用DubboBootstrap的start方法

而这个start方法我在上篇博客Dubbo的启动过程源码分析 – 初始化过程中有初步的讲解， 但是这篇博客我主要还是来探究服务是如何注册到注册中心的。

我在org.apache.dubbo.config.bootstrap.DubboBootstrap#start 加上断点后启动

可以看到调用栈信息， 在finishRefresh方法中会发送事件。 在DubboBootstrapApplicationListener类的onApplicationContextEvent方法中会接受到事件， 并调用了dubboBootstrap.start方法。

ps: 在事件其实经过了OneTimeExecutionApplicationContextEventListener过滤了一下， 他会检查事件是否是框架发送的，如果不是会直接拦截下来的。

开始暴露服务

调用了start方法后，会先初始化， 初始化其实就会加载很多的配置信息等。
然后调用exportServices方法暴露服务， 调用exportMetadataService 暴露元信息， 并注册本地服务。

exportServices 方法

就是遍历之前扫描加载的ServiceConfigBase类， 并逐个调用sc.export();来暴露服务。 很遗憾还要继续往下追溯。

export 暴露服务方法

可以看到前面就是校验参数， 并构建serviceMetadata对象， doExport才是真正的方法。

doExport和doExportUrls方法

图中的红色框中的registerProvider 我其实也不太清楚，感觉是先把服务的名称，序列化方式，调用的接口和真实的服务类放入注册中的本地缓存中。

后面for循环是获取这个服务提供者支持的协议， 并且把每个协议差异化的设置放入循环中，并注册到远程的服务中心。

注册到远程服务中心使用的是doExportUrlsFor1Protocol方法。 我们看下

doExportUrlsFor1Protocol

这个方法有点多，我会分两次截图

图中的红框部分就是把服务的基本信息， 比如协议，进程号， 应用名称， 服务名称等等信息放入到map中。

图中的这一坨在我debug的时候没有进入， 但是看源码 大概就是反射获取ServiceConfig中的方法和方法参数的信息并把这些信息组装好后放入到Map中。

但是为何debug没有进入呢？

通常注册方法到注册中心，都是默认注册所有DubboService类的父接口的方法的。 如果我们想要注册一个方法不在父接口中，这个功能的实现就是在这一坨代码中的。

此处我还有疑惑，希望有人能告诉我

接着往下走

图中就是简单的反射获取接口的所有方法， 并放入到map中。

前面放置了这么多的信息最后还是还放入到serviceMetadata的attachments字段中， 并且还会根据注册中心的host和port等洗信息构建一个URL

此URL是dubbo自己实现的URL类， 这个URL类包含了服务提供者的地址等等信息
我们看下URL的信息。

继续往下debug看看

图中是暴露服务到本地的jvm中的， 因为会出现服务消费者调用本地的服务提供者的情况，这个时候没有必要再去远端调用服务提供者了， 通过本地暴露的服务就可以调用本地的提供者了。 内部细节没有我没有截图， 直接通过了。

继续往下debug

先获取Invoker是代理调用器， 十分重要的一个类， 我们看下是如何实现的。

PROXY_FACTORY.getInvoker

PROXY_FACTORY 就是SPI机制中获取的ProxyFactory类的AdaptiveExtension扩展的。 我们看下

默认使用的是javassist的实现方式， 源码在org.apache.dubbo.rpc.proxy.javassist.JavassistProxyFactory 类中

核心逻辑在org.apache.dubbo.common.bytecode.Wrapper#makeWrapper方法中.

使用javassist 来操作class字节码来生成org.apache.dubbo.common.bytecode.Wrapper类的子类. wrapper的子类会代理调用传入的被代理类， 在debug中被传入的被代理类实际上就是服务提供者类， 生成了子类后会反射生成子类的实例并返回。

所以Dubbo默认获取的Invoker实际上都是通过javassist操作字节码生成的静态代理的类。

PROTOCOL.export(wrapperInvoker)

这里才是真正的注册到远程注册中心的方法。 其中Protocol也是使用的SPI机制获取的扩展实现类。 实现的类是org.apache.dubbo.rpc.protocol.dubbo.DubboProtocol。 可以看下这个类的export方法。

看到打开链接的方法openServer， 其内部就是使用netty来开启socket服务，监听端口（默认20880）开始接收请求了

看源码发现 虽然SPI注解中定义了使用默认的dubbo实现，但是SPI的扩展文件中并没有加载dubbo

因为没有加载到dubbo的SPI实现，这个时候就会根据传入参数中的url来确定协议， 传入参数是Invoker对象， 内部可以获取到URL中值去调用实现类， 我们看下url信息

registry://www.xiezc.xyz:8181/org.apache.dubbo.registry.RegistryService
?application=dubbo-demo-annotation-provider
&dubbo=2.0.2
&export=dubbo://172.18.74.3:20880/org.apache.dubbo.demo.DemoService?anyhost=true
&application=dubbo-demo-annotation-provider
&bind.ip=172.18.74.3&bind.port=20880&deprecated=false&dubbo=2.0.2&dynamic=true
&generic=false&interface=org.apache.dubbo.demo.DemoService&methods=sayHello,sayHelloAsync&pid=83543&release=&side=provider&timestamp=1597053711992&pid=83543&registry=zookeeper&timestamp=1597053706977

内部定义协议的地方有两个， 一个是registry:// , 另外一个是dubbo://