dubbo源码分析7(服务暴露之远程暴露)

  根据上一篇说的,本地暴露服务就是把服务A暴露到当前jvm中,使得当前的jvm中B服务要使用A服务时,就不用去注册中心获取走网络请求的方式,直接从jvm中获取性能会更高;

  那么本篇就说一下服务是怎么暴露到远程的,引用我上一篇写的东西,下图所示,上一篇我们是分析到了步骤2,接下来我们会走完步骤2到步骤6,准备好,开始发车

dubbo源码分析7(服务暴露之远程暴露)

 

  注意,本篇会有很多的代码截图,不会看的很细的,我们首先把流程看完,建议自己也调试一下源码

 

1. 起点

  我们还是从梦开始的地方,打开类org.apache.dubbo.config.ServiceConfig的doExportUrlsFor1Protocol()方法,下图所示

  从这里我们知道,一个服务默认会本地暴露一次,同时还远程暴露一次;  

  而且根据下图中444行,可以知道dubbo暴露服务是可以支持多个协议的,也就是每一种协议都会暴露一份(我们配置文件只配置了dubbo协议)

dubbo源码分析7(服务暴露之远程暴露)

dubbo源码分析7(服务暴露之远程暴露)

 

2. 远程暴露

  从上图中国protocal.export()方法进入,下面这个类在上一篇博客已经说了,需要我们自己手动创建的

dubbo源码分析7(服务暴露之远程暴露)

 dubbo源码分析7(服务暴露之远程暴露)

 dubbo源码分析7(服务暴露之远程暴露)

 

  接下来就是关键的了,下图可以说是包含了整个远程暴露服务的所有核心逻辑了!!!

dubbo源码分析7(服务暴露之远程暴露)

 

3.开启netty服务

  从上图中的步骤1进入

dubbo源码分析7(服务暴露之远程暴露)

 dubbo源码分析7(服务暴露之远程暴露)

 

  为了篇幅的简洁,省略了中间一些没啥用的截图,反正一步一步的就到了下面这里

dubbo源码分析7(服务暴露之远程暴露)

 

  下面的createServer(url)方法就是创建netty服务端了,dubbo中默认netty监听端口是20880,所以平常我们如果本地20880端口占用了,那么启动dubbo服务就会失败的!

dubbo源码分析7(服务暴露之远程暴露)

 

  进入到creatServer()方法

dubbo源码分析7(服务暴露之远程暴露)

 

  可以看到是通过获取exchange之后,去绑定启动netty监听服务

 dubbo源码分析7(服务暴露之远程暴露)

dubbo源码分析7(服务暴露之远程暴露)

 dubbo源码分析7(服务暴露之远程暴露)

 

  省略中间一点没啥用的步骤,反正就是获取NettyTransporter,调用bind方法,然后就是创建nerrtServer实例,NettyServer的继承类图如下所示

dubbo源码分析7(服务暴露之远程暴露)

 

  我们在实例化NettyServer实例的时候,肯定会优先调用父类的构造方法的,在父类AbstractServer构造方法中调用doOpen()方法,这个doOpen()方法是在NettyServer中实现的,最后就是netty框架的使用了

 dubbo源码分析7(服务暴露之远程暴露)

 dubbo源码分析7(服务暴露之远程暴露)

 dubbo源码分析7(服务暴露之远程暴露)

   

  只要是稍微使用过netty的小伙伴,看到下图应该就不陌生了吧!!!(-_-メ)

 dubbo源码分析7(服务暴露之远程暴露)

 

4.连接注册中心zookeeper

  就这一行代码开始去连接注册中心,我们从这里出发

dubbo源码分析7(服务暴露之远程暴露)

dubbo源码分析7(服务暴露之远程暴露)

  

  下面这个类也是需要自己从控制台复制,然后去手动创建

dubbo源码分析7(服务暴露之远程暴露)

 dubbo源码分析7(服务暴露之远程暴露)

 

  到了下图这里,就是封装了zookeeper注册中心的对象了,我们到这里就不继续往里看了;

 dubbo源码分析7(服务暴露之远程暴露)

 

5.创建zookeeper节点

  既然上面已经连接连接好了注册中心,现在就开始根据我们的服务信息去zookeeper中创建节点了

dubbo源码分析7(服务暴露之远程暴露)

 dubbo源码分析7(服务暴露之远程暴露)

 dubbo源码分析7(服务暴露之远程暴露)

 dubbo源码分析7(服务暴露之远程暴露)

 

  下面就是真正的使用工具类api创建zookeeper节点了,详细的过程如下:

 dubbo源码分析7(服务暴露之远程暴露)

 dubbo源码分析7(服务暴露之远程暴露)

 dubbo源码分析7(服务暴露之远程暴露)

  

  然后我们就可以到zookeeper中可以看到provider节点了(注意,这里使用的操作zookeeper的工具是curator,有兴趣的可以花一分钟看看zkClient和curator的区别)

 dubbo源码分析7(服务暴露之远程暴露)

 

6.监听zookeeper节点

  最后就是dubbo订阅zookeeper节点的信息,当服务有数据变化的时候,就会调用回调函数;

  不知道大家有注意看到上图的zookeeper中有个节点是configurators,这个节点就是用于监听的(服务消费者和服务提供者都会去监听这个节点的哦!)

dubbo源码分析7(服务暴露之远程暴露)

dubbo源码分析7(服务暴露之远程暴露)

 dubbo源码分析7(服务暴露之远程暴露)

 dubbo源码分析7(服务暴露之远程暴露)

 

  其实到这里,整个远程服务暴露的逻辑已经过了一遍了

  顺便一提: 注意上图中最后一行的notify方法,这里面会做一些特殊的事情,就是会将dubbo中服务提供者信息给保存成文件,本地磁盘保存一份,这样的话,即使注册中心挂了,但是服务也是可以正常使用的

 dubbo源码分析7(服务暴露之远程暴露)

 dubbo源码分析7(服务暴露之远程暴露)

 dubbo源码分析7(服务暴露之远程暴露)

 dubbo源码分析7(服务暴露之远程暴露)

 

7.总结

  本篇博客没有太多的东西,基本上都是截图,我们走通了整个远程服务暴露的逻辑了,我们现在看看下图,我们终于是走完了步骤0和步骤1的逻辑,服务提供者大概就是这样的;

  dubbo服务提供者会使用一个容器(就是spring的ioc容器)去启动,启动了之后就去将配置文件中的服务信息解析出来,封装成一个个的invoker对象,然后使用protocol将invoker转换为exporter

  在转成exporter的过程中,会首先去启动netty服务端默认监听20880端口,然后去连接zookeeper注册中心,然后就是使用curator操作zookeeper,根据服务信息创建节点provider,写入服务相关信息,并且创建和监听configurators节点,将其中的数据保存一份到本地磁盘

  到此为止,就走完了服务的暴露逻辑

 dubbo源码分析7(服务暴露之远程暴露)

 

上一篇:Dubbo的Random负载均衡


下一篇:Dubbo之Cluster负载均衡