简单学习dubbo

下一个项目要用到dubbo，由于之前项目中没有用过dubbo，所以最近也是从头开始学习，做个笔记。
dubbo官网：http://dubbo.apache.org/en-us/

provider启动的时候会向注册中心把自己的元数据注册上去（服务的ip、端口号等等）
consumer在启动的时候从注册中心订阅，需要注意的是第一次订阅会拉取全量服务提供方的元数据。注册中心发生数据变更的时候会推送给订阅的consumer。在获取服务元数据后，consumer可以发起rpc调用，在rpc调用前后会向监控中心上报统计信息。

分类	dubbo的特性
面向接口代理的高性能RPC调用	提供高性能的基于代理的远程调用能力，服务以接口为粒度，为开发者屏蔽远程调用的底层细节
服务自动注册与发现	支持多种注册中心服务，服务实例上下线实时感知
智能负载均衡	内置多种负载均衡策略，智能感知下游节点健康状况
运行期间流量调度	内置条件、脚本等路由策略，通过配置不同的路由规则，轻松实现灰度发布、同机房优先等功能

Dubbo的核心组件
Dubbo框架中的分层代表了不同的逻辑来实现，它们是一个个组件，这些组件构成了整个dubbo体系。

层次名	作用
service	业务层，包括业务代码的接口和实现
config	配置层
proxy	服务代理层，在dubbo中，无论是生产者还是消费者，框架都会生成一个代理类
registry	注册层
cluster	集群容错层，当远程调用失败时的容错策略
monitor	监控层
protocol	远程调用层，封装rpc调用的具体过程
transport	网络传输层
serialize	序列化层。

解释一下具体的层次作用：
proxy：在dubbo中，无论是生产者还是消费者，框架都会生成一个代理类，整个过程对上层是透明的，当调用一个远程接口时候，看起来就像是调用一个本地接口一样，代理层会自动做远程调用并返回结果，让业务层对远程调用完全无感。

protocol：远程调用层，封装rpc调用的具体过程。protocol是Invoker暴露（发布一个服务让别人可以调用）和引用（引用一个远程服务到本地）的主功能入口，它负责管理Invoker整个的生命周期。Invoker是dubbo的核心模型，框架中所有的其他模型都向它靠拢，或者转换为它，它代表一个可执行体。允许向它发起invoke调用，它可能是执行一个本地的接口实现，可可能是一个远程的实现，还可能是一个集群实现。

serialize：序列化层。如果数据要通过网络进行发送，则需要先做序列化，变成二进制流，序列化层负责整个框架网络传输时的序列化和反序列化。

Dubbo总体调用过程

服务提供者在框架启动的时候，会初始化服务实例，通过proxy组件调用具体的协议（protocol），把服务端要暴露的接口封装成Invoker，然后转成Exporter，这个时候框架会打开服务端口等并记录服务实例到内存中去，最后通过Registry把元数据注册到注册中心，这就是服务端整个接口暴露的过程。

proxy组件：dubbo中只需要引用一个接口就可以调用远程服务了，并且只需要像调用本地方法一样调用就可以。其实dubbo框架为我们生成了代理类，调用方法其实是proxy组件生成的代理方法，会自动发起远程或者本地调用。

protocol组件：协议就是对数据格式的一种约定，它可以把我们对接口的配置根据不同的协议转换成不同的Invoker对象。

Exporter：用于暴露到注册中心的对象。它内部属性持有了Invoker对象。

Registry: 把Exporter注册到注册中心。

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

消费者调用服务提供者的总体流程：
dubbo组件调用整理流程

调用过程也是从一个proxy开始，proxy持有了一个Invoker对象，然后触发invoke调用
在invoke的调用过程中，需要使用Cluster，该组件是负责容错的。
Cluster在调用之前会通过Directory获取所有可以调用的远程服务Invoker列表，如果用户配置了路由规则，那么会根据路由规则将Invoker列表过滤一次。

剩下的Invoker还会有很多，我们需要调用哪个？这个时候就需要用到LoadBalance做负载均衡，最终选择出一个可以调用的Invoker，这个Invoker在调用之前又会经过一个过滤器链，这个过滤器链通过是处理上下文、计数、限流。

Client做数据传输，比如netty，传输之前要做一些私有的协议的构造，此时用到了Codec接口，然后对数据做序列化，然后传输到服务提供者端，服务提供者接受到数据包，处理数据序列化。

然后该请求被分发到线程池中进行处理，Server处理这些请求，根据请求查找出对应的Exporter（内部含有Invoker）.Invoker是被用装饰器模式一层一层套了非常多的filter，所以又会经过一个服务端提供的过滤器链。

最终，我们得到了具体接口的真实实现并调用，再原路把结果返回。

站在整体的角度看dubbo框架做服务暴露可以分为两大部分。
1.将持有的服务实例通过代理转换为Invoker
2.将Invoker通过具体的协议转成Exporter（比如dubbo协议）

这里的Invoker可以简单的理解为一个真实的服务对象实例，是dubbo框架的实体域，所有的模型都向它靠拢，可向它发起invoker调用。它可能是一个本地的实现，也可能是一个远程实现，还可以是个集群实现