01 Dubbo介绍

1 Dubbo是什么

Dubbo是阿里SOA服务化治理方案的核心框架，每天为2000多个服务提供30多亿次访问 量支持，并被广泛应用于阿里集团的各成员站点

1.1 dubbp的基本概念

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

具体来说，Dubbo 在工作时有以下四个角色参与：

1. 服务提供者 - 启动时在指定端口上暴露服务，并将服务地址和端口注册到注册中心上
2. 服务消费者 - 启动时向注册中心订阅自己感兴趣的服务，以便获得服务提供方的地址列表
3. 注册中心 - 负责服务的注册和发现，负责保存服务提供方上报的地址信息，并向服务消费方推送
4. 监控中心 - 负责收集服务提供方和消费方的运行状态，比如服务调用次数、延迟等，用于监控
5. 运行容器 - 负责服务提供方的初始化、加载以及运行的生命周期管

1.2 dubbo的特性

分类	特性
面向接口代理的高性能 RPC调用	提供高性能的基于代理的远程调用能力，服务以接口为粒度，为开发者屏蔽远程调用底层细节
服务自动注册与发现	支持多种注册中心服务，服务实例上下线实时感知
运行期流量调度	内置条件、脚本等路由策略，通过配置不同的路由规则，轻松实现灰度发布、 同机房优先等功能
智能负载均衡	内置多种负载均衡策略，智能感知下游节点健康状况，显著减少调用延迟， 提高系统吞吐量
高度可扩展能力	遵循微内核+插件的设计思想，所有核心能力如Protocol> Transport> Serialization被设计为扩展点，平等对待内置实现和第三方实现
可视化的服务治理与运维	提供丰富服务治理、运维工具：随时查询服务元数据、服务健康状态及调用 统计，实时下发路由策略、调整配置参数

2 Dubbo总体分层

2.1 分层

Dubbo的总体分为业务层(Biz)、RPC层、Remote H层。如果把每一层继续做细分，那么一共可以分为十层。其中，Monitor层在最新的官方PPT中并不再作为单独的一层。

图中左边是具体的分层, 右边是该层中比较重要的接口。

Service和Config两层可以认为是API层，主要提供给API使用者，使用者无须关心底层 的实现，只需要配置和完成业务代码即可；后面所有的层级合在一起，可以认为是SPI层，主 要提供给扩展者使用，即用户可以基于Dubb。框架做定制性的二次开发，扩展其功能。Dubbo 的扩展能力非常强，这也是Dubbo一直广受欢迎的原因之一。

2.2 Dubbo核心组件

Dubbo框架中的分层代表了不同的逻辑实现，它们是一个个组件，这些组件构成了整个 Dubbo体系，在使用方角度更多接触到的可能是配置，更多底层构件被抽象和隐藏了，同时提 供了非常高的扩展性。Dubbo框架之所以能够做到高扩展性,受益于各个组件职责分明的设计，每个组件提供灵活的扩展点。

2.3 Dubbo总体调用过程

2.3.1 服务的暴露过程

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

• Proxy组件：我们知道，Dubbo中只需要引用一个接口就可以调用远程的服务，并且 只需要像调用本地方法一样调用即可。其实是Dubbo框架为我们生成了代理类，调用 的方法其实是Proxy组件生成的代理方法，会自动发起远程/本地调用，并返回结果, 整个过程对用户完全透明。

• Protocol：顾名思义，协议就是对数据格式的一种约定。它可以把我们对接口的配置, 根据不同的协议转换成不同的Invoker对象。例如：用DubboProtocol可以把XML文 件中一个远程接口的配置转换成一个Dubbolnvoker。

• Exporter：用于暴露到注册中心的对象，它的内部属性持有了 Invoker对象，我们可以 认为它在Invoker上包了 一层。

• Registry：把Exporter注册到注册中心。

2.3.2 消费者调用服务提供者的总体流程

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