阿里架构师：详解Dubbo的核心功能、架构思路、应用场景等_阿里dubbo

Dubbo是阿里开源的一个优秀的高性能服务框架。

它的最大特点是按照分层方式进行架构，能让各个层之间解耦合，或最大限度地松耦合，应用通过高性能的RPC，来实现服务提供方的输出，以及服务消费方的输入功能。

看完本篇，将获得以下知识：

1. Dubbo是什么
2. Dubbo的核心功能
3. Dubbo的架构设计
4. Dubbo和HSF的区别
5. Dubbo的四大使用场景

只有了解了这些，大家在后续开发时，才能清楚地知道，该如何去选择、使用。

01 Dubbo是什么

Dubbo是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。

简单的说，Dubbo就是个服务框架，如果没有分布式的需求，其实是不需要用的，只有在分布式的时候，才有Dubbo这样的分布式服务框架的需求，并且本质上是个服务调用的东东，说白了就是个远程服务调用的分布式框架（告别Web Service模式中的WSdl，以服务者与消费者的方式在Dubbo上注册）。

02 Dubbo的核心功能

Dubbo核心功能包含:

1. 远程通讯

提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式。

2. 集群容错

提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。

3. 自动发现

基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。

03 Dubbo的架构设计

Dubbo框架具有极高的扩展性，主要采用微核+插件体系，并且文档齐全，很方便二次开发，适应性极强。

Dubbo的总体架构，如图所示：

 

Dubbo总体架构图

Dubbo架构图注释：

1. 图中左边淡蓝背景的为服务消费方使用的接口；
2. 右边淡绿色背景的为服务提供方使用的接口；
3. 位于中轴线上的为双方都用到的接口；
4. 最上面的Service层是留给实际想要使用Dubbo开发分布式服务的开发者实现业务逻辑的接口层。

Dubbo框架设计一共划分了10个层：

1.服务接口层（Service）

该层是与实际业务逻辑相关的，根据服务提供方和服务消费方的业务设计对应的接口和实现。

2.配置层（Config）

对外配置接口，以ServiceConfig和ReferenceConfig为中心，可以直接new配置类，也可以通过spring解析配置生成配置类。

3.服务代理层（Proxy）

服务接口透明代理，生成服务的客户端Stub和服务器端Skeleton，以ServiceProxy为中心，扩展接口为ProxyFactory。

4.服务注册层（Registry）

封装服务地址的注册与发现，以服务URL为中心，扩展接口为RegistryFactory、Registry和RegistryService。可能没有服务注册中心，此时服务提供方直接暴露服务。

5.集群层（Cluster）

封装多个提供者的路由及负载均衡，并桥接注册中心，以Invoker为中心，扩展接口为Cluster、Directory、Router和LoadBalance。将多个服务提供方组合为一个服务提供方，实现对服务消费方来透明，只需要与一个服务提供方进行交互。

6.监控层（Monitor）

RPC调用次数和调用时间监控，以Statistics为中心，扩展接口为MonitorFactory、Monitor和MonitorService。

7.远程调用层（Protocol）

封装RPC调用，以Invocation和Result为中心，扩展接口为Protocol、Invoker和Exporter。Protocol是服务域，它是Invoker暴露和引用的主功能入口，它负责Invoker的生命周期管理。Invoker是实体域，它是Dubbo的核心模型，其它模型都向它靠拢，或转换成它，它代表一个可执行体，可向它发起invoke调用，它有可能是一个本地的实现，也可能是一个远程的实现，也可能一个集群实现。

8.信息交换层（Exchange）

封装请求响应模式，同步转异步，以Request和Response为中心，扩展接口为Exchanger、ExchangeChannel、ExchangeClient和ExchangeServer。

9.网络传输层（Transport）

抽象mina和netty为统一接口，以Message为中心，扩展接口为Channel、Transporter、Client、Server和Codec。

10.数据序列化层（Serialize）

可复用的一些工具，扩展接口为Serialization、 ObjectInput、ObjectOutput和ThreadPool。

04 Dubbo与HSF的区别

1. Dubbo比HSF的部署方式更轻量

HSF要求使用指定的JBoss等容器，还需要在JBoss等容器中加入sar包扩展，对用户运行环境的侵入性大，如果你要运行在Weblogic或Websphere等其它容器上，需要自行扩展容器以兼容HSF的ClassLoader加载，而Dubbo没有任何要求，可运行在任何Java环境中。

2. Dubbo比HSF的扩展性更好，很方便二次开发

一个框架不可能覆盖所有需求，Dubbo始终保持平等对待第三方理念，即所有功能，都可以在不修改Dubbo原生代码的情况下，在外围扩展，包括Dubbo自己内置的功能，也和第三方一样，是通过扩展的方式实现的，而HSF如果你要加功能或替换某部分实现是很困难的，比如支付宝和淘宝用的就是不同的HSF分支，因为加功能时改了核心代码，不得不拷一个分支单独发展，HSF现阶段就算开源出来，也很难复用，除非对架构重写。

3. HSF依赖比较多内部系统

比如配置中心，通知中心，监控中心，单点登录等等，如果要开源还需要做很多剥离工作，而Dubbo为每个系统的集成都留出了扩展点，并已梳理干净所有依赖，同时为开源社区提供了替代方案，用户可以直接使用。

4. Dubbo比HSF的功能更多

除了ClassLoader隔离，Dubbo基本上是HSF的超集，Dubbo也支持更多协议，更多注册中心的集成，以适应更多的网站架构。

06 Dubbo的使用场景

1.RPC分布式服务

当网站变大后，不可避免的需要拆分应用进行服务化，以提高开发效率，调优性能，节省关键竞争资源等。

比如：为了适用不断变化的市场需求，以及多个垂直应用之间数据交互方便，我们把公共的业务抽取出来作为独立的模块，为其他的应用提供服务，系统逐渐依赖于抽象和rpc远程服务调用。

2.配置管理

当服务越来越多时，服务的URL地址信息就会爆炸式增长，配置管理变得非常困难，F5硬件负载均衡器的单点压力也越来越大。

3.服务依赖

当进一步发展，服务间依赖关系变得错综复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。

4.服务扩容

接着，服务的调用量越来越大，服务的容量问题就暴露出来，这个服务需要多少机器支撑？什么时候该加机器？等等……

在遇到这些问题时，都可以用Dubbo来解决。

-end-

如果觉得不错，请点赞支持下，立即得到下图资料。