Dubbo入门（特性、核心组件、调用过程）

RPC（Remote Procedure Call，远程过程调用）：是一种进程间通信方式，RPC是一种技术思想，而不是规范，它允许程序调用另一个地址空间（通常是共享网络的另一台机器上）的过程或函数，而不是程序员显式编码这个过程调用的细节，即程序员无论是调用本地的还是远程的函数，本质上编写的调用代码基本相同。

RPC的两个核心模块：通讯、序列化

RPC框架：Dubbo、gRPC(Google)、Thrift(Facebook)、HSF（High Speed Service Framework）

1. Dubbo

Apache Dubbo是一款高性能、轻量级的开源Java RPC框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。可以和Spring、SpringBoot框架无缝集成。

1.1 Dubbo的特性

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

总结以下，Dubbo基于这些特性能解决的问题：

• 高性能、透明的RPC调用：Dubbo可以让开发者像调用本地的方法一样调用远程服务，而不需要显式地在代码中指定是远程调用。整个过程对上层开发者透明，Dubbo会自动完成后续的所有操作，例如：负载均衡、路由、协议转换、序列化等。开发者只需要接收对应的调用结果即可。
• 服务的自动注册与发现：当服务越来越多时，服务URL配置管理变得非常困难，服务的注册和发现已经不可能由人工管理。此时需要有一个服务注册中心，动态地注册和发现服务，使服务的位置透明。Dubbo支持多种注册中心，如ZooKeeper、Redis、Consul等。服务消费者可以通过订阅注册中心、及时的知道服务提供者的信息，全程无须人工干预。
• 自动负载均衡与容错：Dubbo提供了完整的集群容错机制，可以实现软件层面的负载均衡，以此降低硬件的压力。Dubbo还提供了调用失败的各种容错机制，如Failover、Failfast、结果集合并…
• 动态流量调度：Dubbo提供了管理控制台，用户可以在界面上动态的调整每个服务的权重、路由规则、启用/禁用，实现运行时的流量调度。
• 依赖分析与调用统计：Dubbo可以接入三方APM（Application Performance Management，应用性能管理）做分布式链路追踪与性能分析，或者使用已有的独立监控中心来监控接口的调用次数及耗时，用户可以根据这些数据反推出系统容量。分布式链路追踪技术对比

1.2 Dubbo的核心组件

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

• Service：业务层，包括业务代码的接口与实现，即开发者实现的业务代码；
• Config：配置层，主要围绕ServiceConfig（暴露的服务配置）和ReferenceConfig（引用的服务配置）两个实现类展开，初始化配置信息。可以理解为该层管理了整个Dubbo的配置；
• Proxy：服务代理层，在Dubbo中，无论生产者还是消费者，框架都会生成一个代理类，整个过程对上层是透明的。当调用一个远程接口时，看起来就像是一个本地的接口一样，代理层会自动做远程调用并返回结果，即让业务层对远程调用完全无感；
• Registry：注册层，负责Dubbo框架的服务注册与发现。每当有新的服务加入或旧服务下线时，注册中心都会感知并通知给所有订阅方。整个过程不需要人工参与；
• Cluster：集群容错层，这一层主要负责：远程调用失败时的容错策略（如失败重试、快速失败）；选择具体调用节点时的负载均衡策略（如随机、一致性Hash等）；特殊调用路径的路由策略（如某个消费者只会调用某个IP的生产者）；
• Monitor：监控层，监控层主要负责监控统计调用次数和调用时间等；
• Protocol：远程调用层。封装RPC调用过程，Protocol是Invoker暴露（发布一个服务让别人可以调用）和引用（引用一个远程服务到本地）的主功能入口，它负责管理整个Invoker的整个生命周期。Invoker是Dubbo的核心模型，框架中所有其他模型都向它靠拢，或者转换成它，他代表一个可执行体。允许向它发起invoke调用，它可能是执行一个本地的接口实现，也可能是一个远程的实现，还可能是一个集群实现；
• Exchange：信息交换层，建立Request-Response（请求-响应）模型，封装请求响应模式，如把同步请求转化为异步请求；
• Transport：网络传输层，把网络传输抽象成统一的接口，如Mina和Netty虽然接口不一样，但是Dubbo在它们上面又封装了统一的接口。用户也可以根据其扩展接口添加更多的网络传输方式；
• Serialize：序列化层，如果数据要通过网络进行发送，则需要先做序列化，变成二进制流。序列化层负责管理整个框架网络传输时的序列化和反序列化工作。

Dubbo核心组件对应的核心配置如下：

配置	配置说明
dubbo:service	服务配置
dubbo:reference	引用配置
dubbo:protocol	协议配置
dubbo:application	应用配置
dubbo:module	模块名称
dubbo:registry	注册中心配置
dubbo:monitor	监控中心配置
dubbo:provider	提供方配置
dubbo:consumer	消费方配置
dubbo:method	方法配置
dubbo:argument	参数配置

1.3 Dubbo总体调用过程

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

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

注：以上是整个服务暴露的过程，消费方在启动时会通过Registry在注册中心订阅服务端的元数据（包括IP和端口）。这样就可以得到刚才暴露的服务了；

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

然后，存活下来的Invoker可能还有很多，此时会继续通过LoadBalance方法做负载均衡，最终选出一个可以调用的Invoker。这个Invoker在调用之前又会经过一个过滤器链，这个过滤器链通常是处理上下文、限流、计数等。

接下来，会使用Client做数据传输，如常见的Netty Client等。传输之前肯定要做一些私有协议的构造，此时就会用到Codec接口。构造完成后，就对数据包做序列化（Serialization），然后传输到服务提供者端。服务提供者接到数据包，也会使用Codec处理协议头及一些半包、粘包等。处理完成后再对完整的数据报文做反序列化处理。

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

最终，我们得到了具体接口的真正实现并调用，再原路把结果返回。至此，一个完整的远程调用过程就结束了。

2. Dubbo的源码

Dubbo源码下载地址：Dubbo，其中包含的模块主要有以下几种：

模块名称	作用
dubbo-common	通用逻辑模块，提供工具类和通用模型
dubbo-remoting	远程通信模块，为服务消费者和服务提供者提供通信能力
dubbo-rpc	容易和remote模块混淆，本模块抽象各种通信协议，以及动态代理
dubbo-cluster	集群容错模块，RPC只关心单个调用，此模块包括负载均衡、集群容错、路由、分组聚合等
dubbo-registry	注册中心模块
dubbo-monitor	监控模块，监控Dubbo接口的调用次数、时间等
dubbo-config	配置模块，实现了API配置、属性配置、XML配置、注解配置等功能
dubbo-container	容器模块，如果项目比较轻量，没用到Web特性，因此不想使用Tomcat等web容器，则可以使用这个main方法加载Spring容器
dubbo-filter	过滤器模块，包含Dubbo内置的过滤器
dubbo-plugin	插件模块，提供内置的插件，如QoS
dubbo-demo	一个简单的远程调用示例模块
dubbo-test	测试模块，包含性能测试、兼容性测试等

3. Dubbo相关

3.1 Dubbo服务治理

• 透明远程调用：就像调用本地方法一样调用远程方法，只需要简单配置，没有任何API侵入；
• 负载均衡机制：Client 端负载均衡，可在内网替代 F5 等硬件负载均衡器；
• 容错重试机制：服务Mock数据，重试次数，超时机制等；
• 自动注册与发现：注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者；
• 性能日志监控：Monitor来统计服务的调用次数和调用时间；
• 服务治理中心：路由规则、动态配置、服务降级、访问控制、权重调整、负载均衡等手动配置；
• 自动治理中心：无，比如：熔断限流机制、自动权重调整等，可使用Spring Cloud提供的Hystrix等等。

3.2 Dubbo的核心功能

• Remote：远程通信，提供对多种NIO框架的抽象封装，包括 “同步转异步” 和 “请求-响应” 模式的信息交换模式；Dubbo底层使用的通信模型是Netty（NIO，同步非阻塞IO）
• Cluster：服务框架，提供基于接口方法的透明远程过程调用，包括协议支持，以及软负载均衡，失败容错、地址路由、动态配置等集群支持；
• Registry：服务注册中心，服务自动发现：基于注册中心目录服务，使服务消费者能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。

3.3 Dubbo的组件角色

• Container：服务运行容器；
• Provider：暴露服务的服务提供方；
• Consumer：调用远程服务的服务消费方；
• Registry：服务注册与发现的注册中心；
• Monitor：统计服务的调用次数和调用时间的监控中心。

调用关系说明：

• 服务容器Container负责启动、加载、运行服务提供者；
• 服务提供者Provider在启动时，向注册中心注册自己提供的服务；
• 服务消费者Consumer在启动时，向注册中心订阅自己所需的服务；
• 注册中心Registry返回服务提供者列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者；
• 服务消费者Consumer，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用；
• 服务消费者Consumer和提供者Provider，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心Monitor。