Dubbo负载均衡集群容错服务降级服务熔断限流

àì夳堔傛蜴生んèń 2021-11-09 14:32 478阅读 0赞

### 一、负载均衡 ###

dubbo默认的负载均默认是随机调用法。一共有4种负载均衡策略：

RandomLoadBalance   随机调用负载均衡；

RoundRobinLoadBlance 轮询调用；

LeastActiveLoadBlance  最少活跃数调用法，使慢的提供者收到更少请求；

ConsistentHashLoadBalance  一致性Hash算法，相同参数的请求总是发到同一提供者；

**配置方式**

可以在服务级别配置，也可以在方法级别配置。

**服务级别：**

服务端服务级别

<dubbo:service interface="..." loadbalance="roundrobin" />

客户端服务级别

<dubbo:reference interface="..." loadbalance="roundrobin" />

**方法级别：**

服务端方法级别

<dubbo:service interface="...">
        <dubbo:method name="..." loadbalance="roundrobin"/>
    </dubbo:service>

客户端方法级别

<dubbo:reference interface="...">
        <dubbo:method name="..." loadbalance="roundrobin"/>
    </dubbo:reference>

**注解版：**

可以在标签上，通过属性，配置负载均衡机制

@Service 
    public class OrderServiceImpl implements OrderService { 
    //@Autowired 
    @Reference(loadbalance="roundrobin") 
    UserService userService;
    @HystrixCommand(fallbackMethod="hello")
    @Override 
    public List<UserAddress> initOrder(String userId) {
    }

### **二、Dubbo集群容错** ###

容错机制指的是系统在一 定范围内允许或包容错误情况的发生。由于各个服务之间存在依赖关系，如果一条链路中的其中一个节点出现故障，将会导致一系列的服务问题至整个系统不可用（雪崩效应）。为了减少某一个节点故障的影响范围，所以我们才需要去构建容错服务（这里要说明一点，容错机制仅仅是处理节点故障的一种机制）， 来优雅的处理这种中断的响应结果。一般是返回固定的错误信息或不访问该节点的服务，这就是“容错”。

**Dubbo提供了6种容错机制，分别如下 **

1.  failsafe 失败安全，可以认为是把错误吞掉（记录日志） ;
2.  failover(默认)   失败重试其他服务器； retries（2） ，缺省的重试次数，不包含第一次;
3.  failfast 快速失败， 失败以后立马报错，也就是只调用一次。通常这种模式用于非幂等性的写操作 ;
4.  failback  失败后自动恢复;
5.  forking  forks. 设置并行数 ;
6.  broadcast  广播，任意一台报错，则执行的方法报错，这种模式通常用于通知所有提供者更新缓存或日志 ;

***消费者端配置方式如下，通过cluster方式，配置指定的容错方案***

<dubbo:reference id="helloService" interface="com.lfv.dubbo.IHello"
    registry="zookeeper" version="1.1.1"
    cluster="failover"/>

配置的优先级别:客户端会优于服务端，这里还可以细化，可以细化到方法级别

1. 方法级优先，接口级次之，全局配置再次之。

2. 如果级别一样，则消费方优先，提供方次之其中，服务提供方配置，通过URL经由注册中心传递给消费方什么应该配置在客户端，什么应该配置在服务端，retires、loadBlance、cluster（客户端）、timeout（服务端）以 timeout 为例，建议由服务提供方设置超时，因为一个方法需要执行多长 时间，服务提供方更清楚，如果一个消费方同时引用多个服务，就不需要关心每个服务的超时设置。

### 三、服务降级 熔断 ###

链路的某个微服务不可用或者响应时间太长时，会进行服务的降级，进而熔断该节点微服务的调用，快速返回错误的响应信息。当检测到该节点微服务调用响应正常后，恢复调用链路。

（一段时间内检测到消费端调用服务端失败或超时达到30%就对该服务进行降级，如果全部失败就熔断该服务不直接调用 而是直接返回一个mock的值）

降级、熔断的目的是为了保证核心服务可用。

降级可以有几个层面的分类： 自动降级和人工降级； 按 照功能可以分为：读服务降级和写服务降级；

1.  对一些非核心服务进行人工降级，在大促之前通过降级 开关关闭哪些推荐内容、评价等对主流程没有影响的功 能 
2.   故障降级，比如调用的远程服务挂了，网络故障、或者 RPC服务返回异常。 那么可以直接降级，降级的方案比 如设置默认值、采用兜底数据（系统推荐的行为广告挂 了，可以提前准备静态页面做返回）等等 
3.   限流降级，在秒杀这种流量比较集中并且流量特别大的 情况下，因为突发访问量特别大可能会导致系统支撑不 了。这个时候可以采用限流来限制访问量。当达到阀值 时，后续的请求被降级，比如进入排队页面，比如跳转 到错误页（活动太火爆，稍后重试等）

**dubbo的降级方式： Mock 机制**

实现步骤：

1. 在client端创建一个TestMock类，实现对应IHello 的接口（需要对哪个接口进行 mock，就实现哪个）， 名称必须以Mock结尾

2. 在client端的xml配置文件中，添加如下配置，增加一 个mock属性指向创建的TestMock

3. 模拟错误（设置 timeout），模拟超时异常，运行测试代码即可访问到TestMock这个类。当服务端故障解除 以后，调用过程将恢复正常

服务端的类及实现类，以及配置文件配置完成后，再在客户端的配置文件的加上mock，具体如下。

<dubbo:reference id="helloService" interface="com.lfv.dubbo.IHello"
    registry="zookeeper" version="1.1.1" timeout="1" cluster="failover"
    mock="com.lfv.dubbo.TestMock"/>

具体Mock机制实现步骤：

首先再客户端添加一个TestMock类，实现IHello接口,配置文件添加好后，这里的配置添加了几个参数 timeout、failover、mock。这里主要是看mock和timeout配置，因为我们是要去验证mock机制，而failover是集群容错的配置，这里没有将这个参数去掉，是因为确定这里他们不会有配置冲突，配置好之后，先发布服务端的服务，然后运行客户端的App.java.在控制台我们可以看到打印结果，系统繁忙，这个结果说明，我们设置1秒超时，客户端远程调用服务超时，报错了，然后就走到了Mock里。