DubboDubbo

什么是RPC

远程过程调用，用于多个服务之间的通信。

 为什么有http还需要rpc框架

rpc可以用http来传输，也可以基于tcp协议传输。http协议比较冗余（http安全、请求头内容繁多等），大部分rpc都是基于tcp的协议。

dubbo结构图

发布-订阅过程：

0)启动容器并加载，运行服务提供者。

1)服务提供者在启动时，在注册中心发布注册自己提供的服务。

2)服务消费者在启动时，在注册中心订阅自己所需的服务。

3)注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。

4)服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。

5)服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。

服务暴露的流程

会在 Spring 实例化完 bean 之后，刷新容器。会根据配置参数组装url（dubbo://192.168.234.1:20880/com.sihai.dubbo.provider.service.ProviderService）。

通过 proxyFactory.getInvoker获取一个Invoker（调用者触发方法用的），利用 javassist 来进行动态代理，封装真的实现类，以便之后反射调用。

同时在第一次暴露的时候会调用 createServer 来创建 Server，默认是 NettyServer（网络传输用，netty是一个nio的非阻塞网络传输框架）。

再通过 URL 参数选择对应的协议进行服务暴露，将 export 得到的 exporter 存入一个 Map 中，供之后的远程调用查找，然后会向注册中心注册提供者的信息。

服务引用方式（引入的是代理类的invoker）

1、在 Spring 容器启动的时候，需要配置 <dubbo:reference> 的 init 属性开启
2、服务被注入到其他类中时引用，默认情况。

服务调用过程

调用某个接口的方法会调用之前生成的代理类，然后会从 容器cluster 中经过路由的过滤、负载均衡机制选择一个 invoker 发起远程调用，此时会记录此请求和请求的 ID 等待服务端的响应。

服务端接受请求之后会通过参数找到之前暴露存储的 map，得到相应的 exporter ，然后最终调用真正的实现类，再组装好结果返回，这个响应会带上之前请求的 ID。

消费者收到这个响应之后会通过 ID 去找之前记录的请求，然后找到请求之后将响应塞到对应的 Future 中，唤醒等待的线程，最后消费者得到响应，一个流程完毕。

协议：

https://www.cnblogs.com/yuandluck/p/9481084.html

服务降级：

在服务宕掉或者并发数太高导致的RpcException异常时，进行友好的处理或者提示，而不是内部报错导致系统不可用。

dubbo提供了mock配置来实现服务降级，mock主要有两种配置方式：

1、服务限流：在远程调用异常时，服务端直接返回一个固定的字符串(也就是写死的字符串)
具体配置：
在服务调用方配置mock参数：
<dubbo:reference id="xxxService" interface="com.x..service.xxxxService" check="false" mock="return 123456..." />

说明：配置了mock参数之后，假设在调用服务的时候，远程服务没有启动，或者各种网络异常了，那远程服务会把这个mock配置的值返回，也就是会返回123456...
通过这种方式就可以避免了因为服务调用不了而出现异常错误而带来的程序不可用(起码是有值返回的，然后可以根据值进行业务逻辑处理判断等等)。

2、在远程调用异常时，服务端根据自定义mock业务处理类进行返回)
具体配置：
在服务调用方配置mock参数：
<dubbo:reference id="xxxService" interface="com.x..service.xxxxService" check="false" mock="true" />

说明：配置了mock参数之后，假设在调用服务的时候，远程服务没有启动，或者各种网络异常了，那远程服务会去寻找自定义的mock业务处理类进行业务处理。
因此还需配置一个自定义mock业务处理类
在接口服务xxxxService的目录下创建相应的mock业务处理类，同时实现业务接口xxxxService()，接口名要注意命名规范：接口名+Mock后缀，mock实现需要保证有无参的构造方法。
public class xxxxServiceMock implements xxxxService {
    @Override
    public String getXXXX(int id) {
        return "this is exception 自定义....";
    }
}
配置完成后，此时如果调用失败会调用自定义的Mock业务实现。

负载均衡：

1.随机模式。按权重设置随机概率。在一个截面上碰撞的概率较高，但调用越大分布越均匀

2.轮询模式。按公约后的权重设置轮询比例。但存在响应慢的服务提供者会累积请求

3.最少活跃调用数。响应快的提供者接受越多请求，响应慢的接受越少请求

4.一致hash。根据服务提供者ip设置hash环，携带相同的参数总是发送的同一个服务提供者，若服务挂了，则会基于虚拟节点平摊到其他提供者上

集群容错：

1、failover, 失败自动切换。这是dubbo的默认集群容错策略，因为它是一个比较通用的策略，即只需做重试即可，保证高可用。

-进行重试时需要刷新invoker，使用负载均衡选择一个invoker，将选中的invoker添加到list中，避免反复选择一个不可用的onvoker，调用选中的invoker。

2、failback 容错，即是只做一次调用，失败后会开启后续定时任务进行重新调用的过程。

-只调用一次，如果失败添加到失败队列中，稍后进行重新请求

3、failfast 容错，快速失败使用负载均衡策略选择一个可用的invoker, 进行调用, 异常则抛出，正常则返回结果。

4、failsafe 容错，即忽略掉所有异常，只返回正式结果。当发生异常时，返回 AsyncRpcResult.newDefaultAsyncResult 作为结果，好像没有发生异常一样。

-与failfast一样，只使用一次负载均衡策略选择一个可用的invoker进习惯调用，区别在于返回值，不抛出异常，当发生异常时返回一个默认值。

5、forking 容错，即是同时发起n个并发请求调用提供者，谁最先响应则返回谁的结果。其他结果则全部忽略。可以说是非常耗资源的一种方式了

-使用线程池（无界队列newCachedThreadPool）并发调用invoker，只要有响应结果，就放到队列中，获取第一个响应结果作为依据。

6、broadcast 容错，即向所有invoker发起调用（即广播），全部成功才算成功。

7、mergeable 容错，依次调用所有invokers, 并通过使用一个merger进行结果合并处理以返回结果