Dubbo源码学习02

Dubbo的架构

provider启动时会向注册中心把自己的元数据注册上去(比如服务ip和端口号)，consumer在启动时从注册中心订阅(第一次订阅会全量拉取数据)服务提供方的元数据，注册中心发生数据变更会推送给订阅的Consumer。在获取服务元数据后，Consumer可以发起RPC调用，在RPC调用前后会向监控中心上报统计信息（比如并发数和调用的接口）

Dubbo的分层

Service和Config层可以认为是API层，主要提供给API使用者，使用者无需关心底层实现，只需要配置和完成业务代码即可。 

Dubbo的核心组件

层次名	作用
Service	业务层。包括业务代码的接口与实现，即开发者实现的业务代码
config	配置层。主要围绕ServiceConfig（暴露的服务配置）和ReferenceConfig（引用的服务配置）两个实现类展开，初始化配置信息。可以理解为该层管理了整个Dubbo的配置
proxy	服务代理层。在Dubbo中，无论生产者还是消费者，框架都会生成一个代理类，整个过程对上层是透明的。当调用一个远程接口时，看起来就像是调用了一个本地的接口一样，代理层会自动做远程调用并返回结果，即让业务层对远程调用完全无感
registry	注册层。负责Dubbo框架的服务注册于发现。当有新的服务加入或旧服务下线时，注册中心都会感知并通知给所有订阅方。整个过程不需要人工参与
cluster	集群容错层。该层主要负责：远程调用失败时的容错策略（如失败重试、快速失败）；选择具体调用节点时的负载均衡策略（如随机、一致性Hash等）；特殊调用路径的路由策略（如某个消费者只会调用某个IP的生产者）
monitor	监控层。这一层主要负责监控统计调用次数和调用时间等
protocol	远程调用层。封装RPC调用具体过程，Protocol是Invoker暴露（发布一个服务让别人可以调用）和引用（引用一个远程服务到本地）的主功能入口，它负责管理Invoker的整个生命周期。Invoker是Dubbo的核心模型，框架中所有其他模型都向它靠拢，或者转换成它，它代表一个可执行体。允许向它发起invoke调用，它可能是执行一个本地的接口实现，也可能是一个远程的实现，还可能一个集群实现
exchange	信息交换层。建立Request-Response模型，封装请求响应模式，如把同步请求转换为异步请求
transport	网络传输层。把网络传输抽象为统一的接口，如Mina和Netty虽然接口不一样，但是Dubbo在它们上面又封装了统一的接口。用户也可以根据其扩展接口添加更多的网络传输方式
Serialize	序列化层。如果数据要通过网络进行发送，则需要先做序列化，变成二进制流。序列化层负责管理整个框架网络传输时的序列化/反序列化工作

Dubbo的总体调用过程

服务提供方：

• 首先服务提供者在框架启动的过程中，会初始化服务实例，通过Proxy组件调用具体的协议(Protocol)，把服务端要暴露的接口封装成Invoker(真实类型是AbstractProxyInvoker)，然后转换成Exporter，这个时候框架会打开端口等记录服务实例到内存中，最后通过Registry把服务元数据注册到注册中心。
• Proxy组件：我们知道，Dubbo中只需要引用一个接口就可以调用远程服务，并且只需要像本地方法一样调用。其实是dubbo框架为我们生成了代理类，调用的方法其实是Proxy组件生成的代理方法，会自动发起远程/本地调用。并返回接口，整个过程对用户是透明的。
• Protocol组件:顾名思义，协议就是对数据格式的一种约定。它可以把我们对接口的配置，根据不同的协议转换成不同的Invoker对象，例如：用DubboProtocol可以吧XML文件中的一个远程接口配置成一个DubboInvoker
• Exporter：用于暴露到注册中心的对象，他的内部属性持有Invoker对象，我们可以认为他在Invoker上包了一层
• Registry：把Exporter注册到注册中心

以上就是整个服务暴露的过程，消费方在启动时会通过Registry在注册中心订阅服务端的元数据，这样就可以得到刚才暴露的服务了。

服务消费方：

• 首先调用过程也是从一个Proxy开始的，Proxy持有了一个Invoker对象。然后触发invoke调用。在invoke调用过程中，需要使用Cluster,Cluster负责容错，如调用失败的重试。Cluster在调用之前会通过Directory获取所有可以调用的远程服务Invoker列表（一个接口可能有多个节点提供服务）。由于可以调用的远程服务节点很多，此时如果用户配置了路由规则（如指定某个方法只能调用某个节点），那么还会根据路由规则将Invoker列表过滤一遍。
• 然后存活下来的Invoker可能还有很多此时要调用哪个呢？于是会继续通过LoadBalance方法做负载均衡，最终选取一个可用的Invoker。这个Invoker在调用之前会经过一个过滤器链，这个过滤器链通常是处理上下文，限流，计数等
• 接着会使用Client做数据传输，比如使用Netty,在传输之前肯定要做一些私有协议的构造，此时就会使用Codec接口。构造完成后，就对数据包进行序列化，然后传输到服务提供者端。服务提供者收到数据包，也会使用Codec处理协议头以及一些半包、粘包等。处理完成后在对完整的数据报文反序列化。
• 随后这个Request会被分配到线程池中进行处理。Server处理这些Request，根据请求查找对应的Exporter(内部持有Invoker)。Invoker是被用装饰器一层层套了非常多的Filter，因此在最终调用最终的实现之前，又会经过服务器端提供的过滤器链。