【转载保存】dubbo学习笔记

Dubbo

Dubbo简介

首先，我理解的Dubbo，从大的方向来看是单体应用到分布式应用过度期的一个产物，具体来说应该是分布式应用从早期的SOA到微服务过度的一个产物。

在编写分布式场景下高并发、高扩展的系统对技能的要求很高，因为这个过程会涉及到序列化/反序列化、多线程、网络编程、设计模式、性能优化等众多专业知识。而Dubbo框架对这些专业知识做了更高层的抽象和封装，提供了开箱即用的特性。所以换句话说Dubbo是为了解决大流量、高并发场景下提供高可用、提升系统性能的这样一个服务治理方案，也是优秀的RPC框架之一，因此被众多公司采用并根据自己的业务实现扩展。

Dubbo具体是一个什么？可不可以在稍微细化说明一下？

上面有提到Dubbo是一个优秀的RPC框架，是Java项目中卓越的框架之一。它提供了注册中心机制，解耦了服务方和消费方动态发现的问题，并提供了高可靠能力，大量采用微内核+富插件设计思想，包括框架自身核心特性都作为扩展点实现，提供了灵活的扩展点能力。

关于Dubbo框架的架构通过下面这张图来先简单了解下，这是dubbo官方提供的，我这边重新画了一下，也是为了加深自己的理解。如下：

1.服务提供者Provider启动时会向注册中心把自己的元数据注册上去（比如服务IP、端口及需要注册的接口定义等信息）；
2.服务消费方Consumer在启动时会从注册中心订阅（第一次订阅会拉取全量数据）服务提供方的元数据；
3.而当注册中心数据发生变更时会推送给订阅的Consumer（比如Provider某个节点Down掉了，又或者服务提供方进行了扩容，增加了节点。）；
4.在Consumer获取到元数据后，Consumer可以发起RPC调用（本质其实是Socket通信+动态代理这样的一个实现机制）；
5.RPC调用前后会向监控中心上报统计信息（比如并发数和调用接口）。

Dubbo特性总结

1.面向接口代理的改性能RPC调用
提供了高性能的基于代理的远程调用能力，服务以接口为粒度，为开发者屏蔽调用的远程细节。

2.服务自动注册与发现
支持多种注册中心服务，服务实例上下线实时感知（上图中的第3步）。

3.运行期流量调度
内置条件、脚本等路由策略，通过配置不同的路由规则，轻松实现灰度发布、同机房优先等功能。

4.智能负载均衡
内置多种负载均衡策略，智能感知下游节点健康状况，显著减少调用延迟，提高系统吞吐量。

5.高度可扩展能力
遵循微内核+插件的设计思想，所有核心能力如Protocol、Transport、Serialization被设计为扩展点，平等对待内置实现和第三方实现。（Dubbo SPI 扩展点机制）

6.可视化的服务治理与运维
提供了丰富服务治理、运维工具（Dubbo Admin）：随时查询服务元数据、服务简况状态及调用统计，实时下发路由策略、调整配置参数。

Dubbo解决的问题

很多同学使用Dubbo有很长一段时间，如果被问起为什么要使用Dubbo，解决了什么问题？我们可能会随口而出：通过RPC调用实现应用间解耦，进而实现将复杂应用微服务化； 保证了系统功能的专一性，进而提高代码或者业务功能的复用性； 分布式的架构设计以及智能的负载均衡提升了我们系统的吞吐量，进而提高了性能……没错，是这样的。但是除了这些可能也回答不出来什么了。这里关于Dubbo解决了什么问题做一下整理，在被别人问道的时候心里也清楚，最关键的是为我们在后续的业务选型上可以做出正确的判断。

一开始就提到了单体应用到分布式的演变，那么随着业务的不断扩展，服务规模和架构的不断演进，在大规模服务化之前，应用可能只是通过Java 的 RMI协议 或Hession等工具实现简单地暴露和引用远程服务，通过配置URL地址进行调用，最后通过F5等硬件进行负载均衡。那既然可以实现简单的远程调用，为什么阿里还要投入这么大成本开发Dubbo呢，当然肯定有必要的一些考量，除了我刚刚提到的那点，Dubbo主要解决以下几个问题：

（1） 高性能、透明的RPC调用。只要涉及服务之间的通信，RPC就必不可。Dubbo可以让我们像调用本地服务一样简单的去调用远程服务，而不需要再代码中显示的指定远程调用。整个过程对上层开发者透明，Dubbo会自动完成后续的所有操作，例如：负载均衡、路由、协议转换、序列化等。开发者只需要接收对应的调用结果。

（2）服务的自动注册与发现。当服务越来越多时，服务URL配置管理变得非常困难，服务的注册与发现已经不可能由人工来管理。此时需要一个注册中心，动态的注册和发现服务，使服务的位置透明。Dubbo适配了多种注册中心。

（3）自动负载与容错。 当服务越来越多时，F5一年负载均衡器的单点压力也原来越大，Dubbo提供了完整的集群容错机制，可以实现软件层面的负载均衡，依次降低硬件的压力。Dubbo还提供了调用失败的各种容错机制，如Failover、Failfast、结果集合并等。

（4）动态的流量调度。在应用运行时，某些服务节点可能因为硬件原因需要减少负载或者某些节点需要人工手动下线；又或者需要实现单元化的调用、灰度功能。通过Dubbo Admin管理控制台，用户可以在界面上动态地调整每个服务的权重、路由规则、禁用/启用，实现运行时的流量调度。

（5）依赖分析和调用统计
Dubbo可以介入第三方的APM做分布式链路追踪与性能分析，或者使用已有的独立监控中心的调用次数及耗时，我们可以通过这些数据反推系统容量，在合适的时候通过加机器进行扩容，并且可以预估需要添加多少台机器。

Dubbo总体分层

下面分享一下Dubbo的分层结构，每一层所做的事情，让我们对Dubbo有一个更进一步的了解。

Dubbo总体分为业务层（Biz）、RPC层、Remote三层。如果把每一层继续细化，那一共可以分为10层。可以参考下图，图中左边是具体的分层，右边是该层中比较重要的接口：

其中Service与Config两层可以认为是API层，主要提供给API使用者，使用者无需关系底层的实现，只需要配置和完成业务代码即可；后面所有层级合在一起，可以认为是SPI层，主要提供给扩展者使用，即用户可以基于Dubbo框架做定制性的二次开发，扩展其功能。提供这个分层图的主要目的是在大家学习期源码的时候可以按照这个分层学习会清晰一下（我也在学习中）。

Dubbo核心组件

在学习任何一个框架或者是存储等之前，了解其核心组件是非常有必要的。Dubbo框架中分层代表了不同的逻辑实现，他们是一个个组件，这些组件构成了整个Dubbo体系，在使用方角度更多接触的可能是配置，更多底层构件被抽象和隐藏了。Dubbo一个很大的特性和亮点便是提供了非常高的扩展性，而这个恰恰得益于各个组件明确的分工设计，每个组件提供了灵活的扩展点，如下：

1.Service层
业务层。包括业务代码接口与实现，即我们自己实现的业务代码。

2.config层
配置层。主要围绕ServiceConfig（暴露的服务配置）和ReferenceConfig（引用的服务配置）两个实现类展开，初始化配置信息。可以理解为该层管理整个Dubbo配置。

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

4.registry层
注册层。服务Dubbo框架的服务注册与发现。当所有新的服务加入或者就服务下线时，注册中心都会感知并通知订阅方。整个过程不需要人工参与。

5.cluster层
集群容错层。主要负责远程调用失败时的容错策略（如失败重试、快速失败）；选择具体调用节点时的复杂均衡策略（如随机、一致性Hash等）；特殊调用路径的路由策略（如某个Consumer只会调用某个IP的Provider）。

6.monitor层
监控层。复杂监控统计调用次数和调用时间等。

7.protocol层
远程调用层。封装RPC调用的具体过程，Protocol是Invoker暴露（发布一个新功能让别人调用）和引用（引用一个远程服务到本地）的主功能入口。它负责管理Invoker的整个生命周期。Invoker是Dubbo哦核心模型，框架中所有其他模型都向它靠拢，或者转换成它，它代表一个可执行体。

8.exchange层
信息交换层。建立Request-Response模型，封装请求响应模式，如吧同步请求转化为一步请求。

9.transport层
网络传输层。把网络传输抽象为同一的接口，如Mina和Netty虽然接口不一样，但是Dubbo在他们上面又封装了统一的接口。我们也可以根据其扩展接口添加更多的网络传输方式。

10.Serialize层
序列化层。如果数据要通过网络进行发送，则需要先做做序列化，变成二进制流。序列化层负责管理整个框架网络传输时的序列化/反序列化工作。

Dubbo总体调用过程

或许目前有些同学还不能理解整个组件穿起来的工作工程，所以先以服务暴露/注册为例子简单描述下。首先服务端（Provider服务提供者）在框架启动时，会初始化服务实例，通过Proxy组件调用具体协议（Protocol），把服务端要暴露的接口封装成Incoker（真实类型时AbstractProxyInvoker），然后转换成Exporter，这个时候框架会打开服务端口等，并记录服务实例到内存中，最后通过Registry吧服务元数据注册到注册中心（比如Zookeeper）。这就是服务端整个接口暴露的过程。关于这里提到了几个组件，在做一下具体的说明：

（1）Proxy组件：我们知道Dubbo中只需哟引用一个接口就可以调用远程的服务。其实是Dubbo框架为我们生成了代理类，调用方法其实也是Proxy组件为我们生成的代理方法，最后会自动发起远程/本地调用，并返回结果，整个过程对我们是完全透明的。
（2）Protocol：其实协议就是对数据的一种约定。它可以把我们对接口的配置通过不同的协议转换成不同的Invoker对象。例如：用DubboProtocol可以把XML文件中一个远程接口的配置转换成一个DubboInvoker。
（3）Exporter：用于暴露到注册中心的对象，它的内部属性持有了Invoker对象，我们可以认为它是在Invoker上包了一层。
（4）Registry：把Exporter注册到注册中心。

以上就是整个服务暴露的过程，如果Consumer在启动时在注册中心订阅了服务端的元数据（实例的IP、端口、实例上暴露的接口信息），这样Consumer就可以得到刚才暴露的服务了。

下面在来看一下Consumer调用服务的整个流程，这里只针对远程调用。Dubbo组件在调用流程中的角色及位置如下图：

首先，调用者从Proxy开始，Proxy持有一个Invoker对象。然后触发Invoker调用。在Invoker调用中，需要使用Cluster负责容错，比如失败重试。Custer在调用之前会通过Directory获取所有可以调用的远程服务Invoker列表（一个接口可能有多个实例/节点提供服务）。由于可以调用的服务有很多，此时如果用户配置了路由规则（如制定某些方法只能调用某个节点），那么Cluster还会根据路由规则将Invoker列表过滤一遍。

然后，存活下来的Invoker可能还会有很多，此时需要调用哪一个呢？这时候会通过loadBalance方位做负载均衡，最终选出一个可以调用的Invoker。这个Invoker在调用前又会经过一个FilterChain（过滤器链），这个FilterChain通常负责处理上下文、限流、计数等。

接着，会使用Client做数据传输，如我们常见的Netty Client等（Socket通信）。传输之前肯定需要做一个私有协议的构造，此时会用到Codec接口（主要作用是负责协议的编解码）。在这之后便是序列化过程了（Serialication）、然后传输到服务提供端。服务提供者接受到数据包，也会使用Codec处理协议头及一些包信息等。处理完之后在对整个报文做反序列化处理。

随后这个请求会被分配到线程池（TheadPool）中进行处理，Server会处理这些请求，根据请求查找赌赢的Exporter（它内部持有了Invoker）。Invoker是被“封装器模式”一层一层套了非常多的Filter的，因此在调用最终的实现类之前，又会经过一个服务提供者端的过滤器链。

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

这里的话整个RPC的调用过程就结束了。