Dubbo入门应用与框架内部设计模型

什么是RPC

维基百科是这么定义RPC的：

在分布式计算，远程过程调用（英语：Remote Procedure Call，缩写为 RPC）是一个计算机通信协议。该协议允许运行于一台计算机的程序调用另一个地址空间（通常为一个开放网络的一台计算机）的子程序，而程序员就像调用本地程序一样，无需额外地为这个交互作用编程（无需关注细节）。RPC是一种服务器-客户端（Client/Server）模式，经典实现是一个通过发送请求-接受回应进行信息交互的系统。

如果涉及的软件采用> 面向对象编程，那么远程过程调用亦可称作> 远程调用或> 远程方法调用，例：> Java RMI。

所以，对于Java程序员而言，RPC就是远程方法调用。

远程方法调用和本地方法调用是相对的两个概念，本地方法调用指的是进程内部的方法调用，而远程方法调用指的是两个进程内的方法相互调用。

如果实现远程方法调用，基本的就是通过网络，通过传输数据来进行调用。

所以就有了：

1. RPC over Http：基于Http协议来传输数据
2. PRC over Tcp：基于Tcp协议来传输数据

对于所传输的数据，可以交由RPC的双方来协商定义，但基本都会包括：

1. 调用的是哪个类或接口
2. 调用的是哪个方法，方法名和方法参数类型（考虑方法重载）
3. 调用方法的入参

所以，我们其实可以看到RPC的自定义性是很高的，各个公司内部都可以实现自己的一套RPC框架，而Dubbo就是阿里所开源出来的一套RPC框架。

什么是Dubbo

官网地址：http://dubbo.apache.org/zh/

目前，官网上是这么介绍的：Apache Dubbo 是一款高性能、轻量级的开源 Java **服务**框架
在几个月前，官网的介绍是：Apache Dubbo 是一款高性能、轻量级的开源 Java **RPC**框架

为什么会将RPC改为服务？

Dubbo一开始的定位就是RPC，专注于两个服务之间的调用。但随着微服务的盛行，除开服务调用之外，Dubbo也在逐步的涉猎服务治理、服务监控、服务网关等等，所以现在的Dubbo目标已经不止是RPC框架了，而是和Spring Cloud类似想成为了一个服务框架。

Dubbo网关参考：https://github.com/apache/dubbo-proxy（社区不是很活跃）

基本原理

入门应用

负载均衡

官网地址：http://dubbo.apache.org/zh/docs/v2.7/user/examples/loadbalance/

如果在消费端和服务端都配置了负载均衡策略，以消费端为准。

这其中比较难理解的就是最少活跃调用数是如何进行统计的？

讲**道理，最少活跃数应该是在服务提供者端进行统计的，服务提供者统计有多少个请求正在执行中。
但在Dubbo中，就是不讲道理，它是在消费端进行统计的，为什么能在消费端进行统计？

逻辑是这样的：

1. 消费者会缓存所调用服务的所有提供者，比如记为p1、p2、p3三个服务提供者，每个提供者内都有一个属性记为active，默认位0
2. 消费者在调用次服务时，如果负载均衡策略是leastactive
3. 消费者端会判断缓存的所有服务提供者的active，选择最小的，如果都相同，则随机
4. 选出某一个服务提供者后，假设位p2，Dubbo就会对p2.active+1
5. 然后真正发出请求调用该服务
6. 消费端收到响应结果后，对p2.active-1
7. 这样就完成了对某个服务提供者当前活跃调用数进行了统计，并且并不影响服务调用的性能

服务超时

在服务提供者和服务消费者上都可以配置服务超时时间，这两者是不一样的。

消费者调用一个服务，分为三步：

1. 消费者发送请求（网络传输）
2. 服务端执行服务
3. 服务端返回响应（网络传输）

如果在服务端和消费端只在其中一方配置了timeout，那么没有歧义，表示消费端调用**服务的超时时间，消费端如果超过时间还没有收到响应结果，则消费端会抛超时异常，但，服务端不会抛异常，服务端在执行服务后，会检查执行该服务的时间，如果超过timeout，则会打印一个超时日志**。服务会正常的执行完。

如果在服务端和消费端各配了一个timeout，那就比较复杂了，假设

1. 服务执行为5s
2. 消费端timeout=3s
3. 服务端timeout=6s

那么消费端调用服务时，消费端会收到超时异常（因为消费端超时了），服务端一切正常（服务端没有超时）。

集群容错

官网地址：http://dubbo.apache.org/zh/docs/v2.7/user/examples/fault-tolerent-strategy/

集群容错表示：服务消费者在调用某个服务时，这个服务有多个服务提供者，在经过负载均衡后选出其中一个服务提供者之后进行调用，但调用报错后，Dubbo所采取的后续处理策略。

服务降级

官网地址：http://dubbo.apache.org/zh/docs/v2.7/user/examples/service-downgrade/

服务降级表示：服务消费者在调用某个服务提供者时，如果该服务提供者报错了，所采取的措施。

集群容错和服务降级的区别在于：

1. 集群容错是整个集群范围内的容错
2. 服务降级是单个服务提供者的自身容错

本地存根

官网地址：http://dubbo.apache.org/zh/docs/v2.7/user/examples/local-stub/

本地存根，名字很抽象，但实际上不难理解，本地存根就是一段逻辑，这段逻辑是在服务消费端执行的，这段逻辑一般都是由服务提供者提供，服务提供者可以利用这种机制在服务消费者远程调用服务提供者之前或之后再做一些其他事情，比如结果缓存，请求参数验证等等。

本地伪装

官网地址：http://dubbo.apache.org/zh/docs/v2.7/user/examples/local-mock/

本地伪装就是Mock，Dubbo中Mock的功能相对于本地存根更简单一点，Mock其实就是Dubbo中的服务容错的解决方案。

参数回调

官网地址：http://dubbo.apache.org/zh/docs/v2.7/user/examples/callback-parameter/

官网上的Demo其实太复杂，可以看课上的Demo更为简单。

首先，如果当前服务支持参数回调，意思就是：对于某个服务接口中的某个方法，如果想支持消费者在调用这个方法时能设置回调逻辑，那么该方法就需要提供一个入参用来表示回调逻辑。

因为Dubbo协议是基于长连接的，所以消费端在两次调用同一个方法时想指定不同的回调逻辑，那么就需要在调用时在指定一定key进行区分。

异步调用

官网地址：http://dubbo.apache.org/zh/docs/v2.7/user/examples/async-call/

理解起来比较容易，主要要理解CompletableFuture，如果不理解，就直接把它理解为Future

其他异步调用方式：https://mp.weixin.qq.com/s/U3eyBUy6HBVy-xRw3LGbRQ

泛化调用

官网地址：http://dubbo.apache.org/zh/docs/v2.7/user/examples/generic-reference/

泛化调用可以用来做服务测试。

在Dubbo中，如果某个服务想要支持泛化调用，就可以将该服务的generic属性设置为true，那对于服务消费者来说，就可以不用依赖该服务的接口，直接利用GenericService接口来进行服务调用。

泛化服务

官网地址：http://dubbo.apache.org/zh/docs/v2.7/user/examples/generic-service/

实现了GenericService接口的就是泛化服务

Dubbo中的REST

官网地址：http://dubbo.apache.org/zh/docs/v2.7/user/rest/

注意Dubbo的REST也是Dubbo所支持的一种协议。

当我们用Dubbo提供了一个服务后，如果消费者没有使用Dubbo也想调用服务，那么这个时候我们就可以让我们的服务支持REST协议，这样消费者就可以通过REST形式调用我们的服务了。

注意：如果某个服务只有REST协议可用，那么该服务必须用@Path注解定义访问路径

管理台

github地址：https://github.com/apache/dubbo-admin

动态配置

官网地址：http://dubbo.apache.org/zh/docs/v2.7/user/examples/config-rule/

注意动态配置修改的是服务参数，并不能修改服务的协议、IP、PORT、VERSION、GROUP，因为这5个信息是服务的标识信息，是服务的身份证号，是不能修改的。

服务路由

官网地址：http://dubbo.apache.org/zh/docs/v2.7/user/examples/routing-rule/

什么是蓝绿发布、灰度发布

https://zhuanlan.zhihu.com/p/42671353

Dubbo底层网络连接模型

在Dubbo中，有两个参数用来配置服务消费者和服务提供者直接的socket连接个数：

1. shareconnections：表示可共享的socket连接个数
2. connections：表示不共享的socket连接个数

服务A的shareconnections为2时，服务A的消费者会向服务A的提供者建立两个socket连接：


服务A的connections为2时，服务A的消费者会向服务A的提供者建立两个socket连接：



当某个消费者应用引入了同一个服务的两个版本（这两个版本共用一个端口号：20881），这时如果shareconnections为2，则在消费端这边所引入的两个版本服务会共享这两个socket连接，如果有3个版本，也会共享这两个socket连接。**

当某个消费者应用引入了同一个服务的两个版本（这两个版本共用一个端口号：20881），这时如果connections为2，则在消费端这边所引入的两个版本服务会单独拥有两个socket连接，如果有3个版本，就会有3个socket连接。
**

Dubbo消费端的线程模型

在整个消费者调用过程中，最关键的是DefaultFuture，DefaultFuture起到的最用是衔接Request和Response，既保证了非阻塞调用，也达到了Request-Response模型。

Dubbo服务端的线程模型

在整个消费者调用过程中，各个线程池都比较重要，其中比较有特色的就是AllChannelHandler，它完成了IO线程转向用户线程的任务转移，比较关键。

Dubbo服务端和消费端Handler模型

Dubbo服务调用完整流程

Dubbo整体架构图