概述
Dubbo是一款高性能、轻量级的开源Java RPC框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。2018年由阿里巴巴捐献给Apache基金会，目前已经正式成为Apache开源项目之一。
Dubbo特性
作为一个分布式服务框架，以及SOA治理方案，Dubbo提供了许多有用的特性，帮助快速开发分布式服务应用以及运营维护，相关特性包括
- 面向接口代理的高性能RPC调用
提供高性能的基于代理的远程调用能力，服务以接口为粒度，为开发者屏蔽远程调用底层细节。
- 服务自动注册与发现
支持多种注册中心服务，服务实例上下线实时感知。
- 运行期流量调度
内置条件、脚本等路由策略，通过配置不同的路由规则，轻松实现灰度发布，同机房优先等功能。
- 智能负载均衡
内置多种负载均衡策略，智能感知下游节点健康状况，显著减少调用延迟，提高系统吞吐量。
- 高度可扩展能力
遵循微内核+插件的设计原则，所有核心能力如Protocol、Transport、Serialization被设计为扩展点，平等对待内置实现和第三方实现。
- 可视化的服务治理与运维
提供丰富服务治理、运维工具：随时查询服务元数据、服务健康状态及调用统计，实时下发路由策略、调整配置参数。
Dubbo架构
Dubbo的整体架构分为如下容器和服务提供者、服务消费者、注册中心、监控中心等四大部分，其整体的架构和执行流程如下图所示
Dubbo架构
- 服务容器Container
服务容器负责启动，加载，运行服务提供者。
- 服务提供者Provider
在启动时，向注册中心注册自己提供的服务。
- 服务消费者Consumer
在启动时，向注册中心订阅自己所需的服务。
- 服务注册中心Registry
服务注册与发现的中心，提供目录服务。服务提供者将服务注册到注册中心，服务消费者从服注册中心订阅服务，获取服务提供者服务列表；如果服务提供者的服务列表有变更，注册中心将基于长连接推送变更数据给服务消费者。
- 监控中心Monitor
统计服务的调用次数、调用时间等信息的日志服务，并可以对服务设置权限、降级处理等，也称为服务管控中心。
Dubbo核心组件
Dubbo官方将Dubbo核心组件总体分为Business业务层、RPC层、Remoting层，继续细分的话可以分为10层。其分层结构如下图所示
Dubbo核心组件分层
从使用者角度分类的话，可以分成API层和SPI扩展层。其中的Service和Config两层可以认为是API层，主要提供给API使用者，只需要配置和完成业务代码即可；剩下的其它层级合在一起，可以认为是SPI层，主要提供给扩展者使用，让用户可以基于Dubbo框架做定制性的二次开发，扩展其功能。
- Service
业务层，包括业务代码的接口和实现，即开发者实现的业务代码。
- Config
配置层，主要围绕服务提供者ServiceConfig和服务消费者ReferenceConfig两个配置实现类展开，初始化配置信息。可以理解为Dubbo的配置管理层。
- Proxy
服务代理层，无论服务提供者或消费者，Dubbo框架都会生成一个代理类，封装了所有接口的透明化代理，代理远程接口的调用。
- Registry
注册层，负责Dubbo框架的服务注册和发现。服务上线或下线，注册中心都会感知并通知给所有订阅方，无需人工参与。实际上不算一层，而是一个独立的节点，只是为了全局概览，用层的方式划分在一起，后面的Monitor层也是如此。
- Cluster
集群容错层，该层主要负责远程调用失败时的容错策略(如失败重试、快速失败等)、选择具体调用节点时的负载均衡策略(如随机、一致性哈希等)、特殊调用路径的路由策略(如某个消费者只调用特定IP的提供者)。 Cluster层是外围概念，Cluster 的目的是将多个 Invoker 伪装成一个 Invoker，这样其它人只要关注 Protocol 层 Invoker 即可，加上 Cluster 或者去掉 Cluster 对其它层都不会造成影响，因为只有一个提供者时，是不需要 Cluster 的。
- Monitor
监控层，主要负责监控统计服务调用次数和调用时间等信息。实际上不算一层，而是一个独立的节点，只是为了全局概览，用层的方式划分在一起。
- Protocol
协议层，也称为远程调用层，封装RPC调用具体过程。Protocol是Invoker发布(曝露)和引用服务的主功能入口，它负责管理Invoker的整个生命周期。Invoker是Dubbo的核心模型，框架中所有其它模型都向它靠拢，或者转换成它，它代表一个可执行体。允许向它发起invoke调用，它可能是执行一个本地的接口实现，也可能是一个远程的实现，还可能是一个集群实现。Protocol 是核心层，实际上只要有 Protocol + Invoker + Exporter 就可以完成非透明的 RPC 调用。
- Exchange
信息交换层，负责建立请求-响应模型(Request-Response)，封装请求响应模式，比如把同步请求转化为异步请求。
- Transport
网络传输层，Transport 层只负责单向消息传输，是对 Mina, Netty, Grizzly 的抽象，它也可以扩展 UDP 传输。用户也可以根据其它扩展接口添加更多的网络传输方式。
- Serialize
序列化层，负责Dubbo框架网络传输时消息的序列化和反序列化工作，即把消息对象转换为二进制流或把二进制流转化为消息对象。
其中的Service完全由开发者提供的业务代码，在剩下的其它9层中，Dubbo提供了许多重要的接口，下图是这些重要接口的概览
Dubbo各层重要接口
服务消费调用链
服务提供者通过注册中心曝露服务后，在服务消费者端订阅服务，当由用户请求时，便开始调用远程服务。调用远程服务的过程中，各组件接口的调用关系及调用链如下
服务消费过程各组件接口调用链
整个调用链较核心流程大致如下：
首先，调用过程是从Proxy开始的，Proxy会经过一个过滤器，持有了一个Invoker对象，然后触发invoke调用。在invoke调用过程中，需要使用Cluster负责容错重试。Cluster在调用之前会通过Directory获取所有可以调用的远程服务Invoker列表(一个接口可能由多个节点提供服务)。由于可以调用的远程服务有很多，此时如果用户配置了路由规则，那么还会根据路由规则将Invoker列表过滤一遍。
然后，过滤之后的Invoker可以还不止1个，此时还需继续通过LoadBalance方法做负载均衡，最终选出一个可以调用的Invoker。这个Invoker在调用之前会经过一个Filter过滤器链，这个过滤器链通常是处理上下文、限流、计数等。
接着，会使用Client做数据传输，一般就是Netty或Mina的客户端。传输之前，需要做一些私有协议的封装改造，此时会用到Codec接口。封装完成后，调用Serialization对数据包(消息)做巡序列化，然后通过网络将请求发送到服务提供者。服务提供者收到请求后，对数据包使用Serialization和Codec反序列化和协议解析。
随后，这个Request请求会被分配到线程池(ThreadPool)中进行处理。Server会处理这些Request，根据请求查找到对应的Exporter(它内部持有Invoker)。Invoker是被用装饰器模式一层一层套了非常多Filter的，因此在调用最终实现类之前，又会经过一个服务提供者端的过滤器链。
最终，调用了具体接口的真正实现类的服务，然后原路把结果返回。
至此，一个完整的远程调用结束。
总结
Dubbo是一款高性能、轻量级的开源分布式服务框架，本质上是个远程服务调用RPC框架，简单的理解就是一个远程服务调用的分布式框架。Dubbo常用于分布式服务架构或流动计算架构应用中，与之类似的框架还有Spring Cloud等。
#java开发工程师# #架构师#
