Dubbo服务消费原理
关注可以查看更多粉丝专享blog~
概述
前面已经讲过Dubbo服务暴露的原理了（传送门），今天分析一下Dubbo服务消费原理，相比于服务暴露原理，服务消费就有点像把暴露原理倒过来，可以看一下消费原理图。跟服务暴露的流程很相似，只是服务暴露的核心类是ServiceConfig，服务消费的核心类是ReferenceConfig，从名字上也可以看出来。
服务暴露流程是ServiceConfig --> ProxyFactory --> Invoker --> Protocol --> Exporter
服务消费流程是ReferenceConfig --> Protocol --> Invoker --> ProxyFactory --> ref
一个是把本地的推倒远端，一个是把远端的代理到本地，像本地调用一样的进行远程调用，具体是否调用本地或者远端，对于我们来说是透明的，Dubbo已经帮我们封装好了。
整体上看，Dubbo框架做服务消费也分为两大部分：
- 通过持有远程对象实例生成Invoker，这个Invoker在客户端是核心的远程代理对象。
- 把Invoker通过动态代理转换成实现用户接口的动态代理引用。
这里Invoker承载了网络连接、服务调用和重试等功能，在客户端，它可能是一个远程的实现，也可能是一个集群的实现。
框架真正进行服务引用的入口点在ReferenceBean#getObject，不管是XML还是注解，都会转换成ReferenceBean，它继承自ReferenceConfig。
服务消费过程
- 优先判断是否处于同一个JVM里面，默认场景下Dubbo会找出内存中的injvm协议的服务（服务暴露时会注册一份到injvm，将服务实例放到内存map中）直接获取实例调用。
- 在注册中心追加消费者元数据信息，应用启动时订阅注册中心、服务提供者参数等合并时会用到这部分信息。
- 处理只有一个注册中心的场景，这种场景在客户端中是最常见的，客户端启动拉取服务元数据，订阅provider、路由和配置变更。
- 处理多注册中心的场景。逐个获取注册中心的服务，并添加到invokers列表中，后面通过Cluster将多个Invoker转换成一个Invoker。
相关文章：
Davids原理探究：Dubbo源码编译（2.7.8）
Davids原理探究：Dubbo SPI和Java SPI实现原理
Davids原理探究：Dubbo注册中心（ZooKeeper、Redis）实现原理
Davids原理探究：Dubbo配置解析原理
Davids原理探究：Dubbo服务暴露原理
Davids原理探究：Dubbo服务消费原理
Davids原理探究：Dubbo优雅停机原理解析
Davids原理探究：Dubbo调用流程图
Davids原理探究：Dubbo路由实现原理
Davids原理探究：Dubbo负载均衡实现原理
Davids原理探究：Dubbo过滤器原理