3_Dubbo

Dubbo

1）分布式通信的两种方式：（面试）

        在分布式架构中，分布式通信的两种方式：**RPC通信、HTTP通信；**
        RPC通信的效率要高于HTTP通信。（详情看CSDN）

2）图解分布式架构：

        特点：将项目根据不同的功能和应用场景划分为不同的独立的模块，各个模块之间可以进行互相的调用。（**针对负载较大的模块，可以给它加上集群，再利用负载均衡的策略，使得每个服务器的负载都差不多，以解决服务器压力过大、瘫痪宕机的问题**）。

                           ![](mdpic/wps2.jpg#alt=img)

3）架构的演进：

1单体架构 2垂直架构 3分布式架构 4流式架构

4）dubbo的体系结构图：（面试）

这里的Container容器指的其实就是我们的Spring容器；


第1步：编写，并启动提供者。（启动的时候将提供者的信息注册到注册中心，异步的方式）； 


第2步：编写，并启动消费者；
         （启动的时候，消费者会去注册中心订阅指定的服务，
           同时：注册中心返回 提供者的地址列表 给消费者）；

第3步：消费者从提供者地址列表中，基于负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。

第4步，在内存中累计`服务调用的信息`（即，服务调用的次数和时间），并且定时每分钟 异步的发送一次 服务调用的信息 到监控中心。

5) Monitor监控中心

    Monitor在整个架构中 是可选的 （图中的虚线并不是可选的意思），Monitor挂掉并不会影响服务的调用。
    在moniter监控中心中，可以监控到注册中心的各种信息和活动。

6）dubbo的5大特点：（面试）

1>面向接口的远程方法调用;
        服务之间仅需通过 方法的调用 便完成了rpc远程过程调用。为开发者屏蔽了RPC远程过程调用的底层细节。

2>智能容错与负载均衡;
        所有的应用都需要在注册中心注册，注册中心会根据流量情况，智能的为请求挑选合适的服务器。

3>服务的自动注册与发现;

4>支持多种协议;
         默认是dubbo协议；
         还支持RMI、Hessian、HTTP、Redis、Memcached等多种协议。

7）RPC（远程过程调用）框架的底层原理：（面试）

影响RPC远程调用的性能的两个点：
    1. 序列化和反序列化的速度；
    2. 建立Socket连接和传输数据的时间;

RPC远程过程调用流程：

远程过程调用包含如下步骤：

1）消费者（client）请求服务，开始调用 （client stub）消费者存根/助手； 

2）（client stub）消费者助手收到调用后，将请求数据进行序列化（序列化成二进制的文件）； 

3）然后，消费者助手通过Socket端口，将请求数据发送到 提供者端的Socket端口； 

4）（server stub）提供者助手，通过Socket端口收到数据后，将请求数据进行 反序列化； 

5）然后（server stub）提供者助手将 请求数据 交给提供者；

6）提供者处理请求后，将响应结果 返回给（server stub）提供者助手； 

7）（server stub）提供者助手 将响应结果序列化（序列化成二进制的文件），并通过Socket端口 发送给消费者端的Socket端口； 
8）（client stub）消费者助手 通过Socket端口收到响应数据后，将响应数据进行反序列化； 

9）然后（client stub）消费者助手将响应结果交给 消费者。

   结束。

dubbo为开发者封装了RPC远程过程调用的底层细节。

@1：注意：

在两个socket端口之间进行通讯，即传递数据，用的是NIO。

@2：注意：

消费者和提供者，是需要我们自己写的   

2（即消费者存根/助手、提供者存根/助手、Socket端口这些）是dubbo给封装好的，不扒源码是看不到的，

5）dubbo可以有多个注册中心

dubbo 这几个都可以作为注册中心，但dubbo官方推荐的是zookeeper

8） dubbo的4种负载均衡策略.（面试）

1. 负载均衡机制.

一共四种方式：
           - 随机（按权重设置）
           - 轮询（按权重设置）
           - 最少活跃调用数
           - 一致性哈希

---------------------------------

1、随机，Random LoadBalance
    随机，按权重设置随机概率。
    调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。
    比如： 三台服务提供者，权重分别为100、200、50，按照基于权重的随机负载均衡机制，请求这三个服务的概率分别为2/7,4/7和1/7。 

2、轮询、RoundRobin LoadBalance
    轮询，按公约后的权重设置轮询比率。
    存在慢的提供者累积请求的问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。

3、最少活跃调用数，LeastActive LoadBalance
    最少活跃调用数， 
    使慢的提供者收到更少的请求。
    哪台机器处理快,就将请求交给哪台提供者.

4、一致性哈希，ConsistentHash LoadBalance
    一致性 Hash，相同消费者的请求总是发到同一提供者。
    当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。

3）Dubbo的6种集群容错策略

        - 失败重试（Failover Cluster）--默认策略

        - 快速失败（Failfast Cluster）--失败了就失败了

          - 失败安全（Failsafe Cluster）--即，忽略失败

          - 失败自动恢复（Failback Cluster）--记录失败，后期再重试

          - 并行调用（Forking Cluster）--一台成功则成功

          - 广播调用（Broadcast Cluster）--一台失败则失败

Failover Cluster：失败重试
    当服务消费方调用服务提供者失败后，自动切换到其他服务提供者服务器进行重试。这通常用于读操作或者具有幂等的写操作，需要注意的是重试会带来更长延迟。
    可通过 retries="2" 来设置重试次数（不含第一次）。如上配置，当服务消费方调用服务失败后，会再重试两次，也就是说最多会做三次重试。


Failfast Cluster：快速失败
    当服务消费方调用服务提供者失败后，立即报错，也就是只调用一次。通常这种模式用于非幂等性的写操作。


Failsafe Cluster：失败安全
    当服务消费者调用服务出现异常时，直接忽略异常。这种模式通常用于写入审计日志等操作。


Failback Cluster：失败自动恢复
    当服务消费端用服务出现异常后，在后台记录失败的请求，并按照一定的策略，后期再进行重试。这种模式通常用于消息通知操作。


Forking Cluster：并行调用
    消费方会并行调用多个服务提供者的服务，只要一个成功即返回。这种模式通常用于实时性要求较高的读操作，但需要浪费更多服务资源。可通过 forks="2" 来设置最大并行数。


Broadcast Cluster：广播调用
    消费者会逐个调用所有的服务提供者，一台出现异常，就标志这次调用失败。这种模式通常用于通知所有提供者更新缓存或日志等本地资源信息。