Dubbo中的高级配置(一)

负载均衡
在生产环境中，每个服务通常为一个集群，则需要进行负载均衡。

dubbo中的负载均衡算法
dubbo中内置了四种负载均衡算法。

random：随机算法，是默认的负载均衡策略。
roundrobin：轮询算法。按照权重进行访问，权重设置在提供者端，数值越大，权重越大。
leastactive：最少活跃度算法
consistenthash：一致性hash算法。

 

 

======================================

 

 

 

dubbo中的集群容错
集群容错指的是，当消费者调用提供者集群时发生异常的处理方案。在dubbo中，内置了6种集群容错方式。

Failover
Failover是故障转移机制，当消费者服务调用提供者服务某个服务器无法响应时，其会尝试调用同服务的其他服务器，适用于读操作。比如，消费者调用提供者从数据库中读取数据，可以设置retires来决定其重试次数，重试次数不包含第一次的正常调用。当第一次读取数据失败时，可以进行重试，尝试调用其他服务器服务，进行故障的转移。

Failfast
Failfast即快速失败机制，当服务消费者调用服务提供者时，服务无法正确相应时，则立即报错。通常适用于非幂等性的写操作，例如新增一条数据记录。

ps：所谓幂等性，每次发出请求对服务端产生的状态影响是幂等的，任意次执行对资源本身所产生的影响和执行一次是相同的。

Failsafe
Failsafe即失败安全机制，当服务消费者调用服务提供者时，服务无法正确响应时，直接忽略本次消费请求。通常适用于不太重要的服务，如日志写入操作等。

Failback
Failback即失败自动回复机制，当服务消费者调用服务提供者，服务未正常相应，dubbo会记录本次失败记录，后面定时自动重新发送该请求。通常适用于对实时性要求不高的服务，如消息的通知等。

Forking
Foring即并行机制，消费者会同时调用服务提供者的多台服务器，当有一台服务器返回结果，即调用成功。通常适用于对实时性要求高的操作，但会造成服务器资源的浪费。

Broadcast
Broadcast即广播机制，会逐个调用服务提供者，若有一个出现失败则会报错。通常适用于通知所有提供者更新缓存、日志等信息时使用。

在dubbo中，默认的集群容错方式为故障转移机制(Failover)，可以通过在服务提供者端的<dubbo:service>或者服务消费者端的<dubbo:reference>中添加cluster参数进行更改。

服务降级
何为服务降级
服务降级，当服务器压力剧增的情况下，根据当前业务情况以及流量对一些服务有策略的降低服务级别，释放更多的服务器资源，保证核心业务的正常运行。例如：在双十一0点-2点期间，淘宝不允许用户查看历史订单；在晚上11点至次日7点，12306停止售票服务。这都是典型的服务降级。

服务降级的方式
能够实现服务降级的方式由很多，常见的方式由以下几种情况：

部分服务暂停。比如双十一期间淘宝的不允许用户查看历史订单，就属于暂停了这部分业务。
部分服务延迟。
全部服务暂停。典型的代表就是12306的夜间服务停止操作。
随机拒绝服务。
服务降级与mock机制
在dubbo中服务降级采用的为mock机制，具有两种降级处理方式：Mock Null降级处理与Class Mock降级处理。在适用场景方面，Mock Null降级处理适用于没有返回值的情况，Class Mock降级处理则适用于没有返回值的情况。

在测试服务降级时，要模拟服务提供失败的情况，用不启动服务提供者的方式来模拟，只需要修改消费者端即可。Dubbo对于存在返回值和无返回值的服务降级处理方式不同，定义如下所示接口，包含一个有返回值的方法和一个无返回值的方法。
 

======================================

服务限流
在dubbo中同样提供了服务限流的两种方法：直接限流和间接限流。直接限流，通过对连接的数量直接限制来达到限流的目的，超时限制则会让消费者等待，直到等待超时，或者获取到服务。间接限流，通过一些非连接数量设置的间接手段来达到限流的目的

直接限流
executes限流
该属性仅能设置在提供者端。可以设置为接口级别，也可以设置为方法级别。
<!-- 限制当前接口中的每个方法并发连接数不超过10 -->
    <dubbo:service interface="com.abc.service.SomeService"
                   ref="zhifubaoService" executes="10"/>
    <!-- 限制当前接口中hello方法服务并发数量不超过10 -->
    <dubbo:service interface="com.abc.service.SomeService"
                   ref="weixinService">
        <dubbo:method name="hello" executes="10"/>
    </dubbo:service>

accepts限流

该属性仅可设置在提供者端的dubbo:protocol/与dubbo:provider/标签中，用于对指定协议连接数的限制。前者基于协议连接数量限定的，而后者是针对服务本身在使用某种协议时最多接受多少个消费者连接。

 <!-- 限制当前接口在dubbo协议下并发连接数不超过10 -->
    <dubbo:protocol name="dubbo" port="20880" accepts="10"/>
    <dubbo:provider protocol="dubbo" accepts="10"/>
 

 

actives限流
actives限流方式既可以在提供者方设置也可以在消费者方设置，同时消费者调用的长连接、短连接意义有所不同。

在提供者方设置时，若客户端与当前服务的连接为长连接，则表示当前服务的一个长连接可以并行处理请求的数目；若客户端与当前服务的连接为短连接时，则表示当前服务可以同时处理的短连接的数量。
在消费者方设置时，若连接为长连接，则表示当前客户端一个长连接能够并发提交请求的个数，并没有长连接数目的限制；若连接为短连接，则表示当前客户端能够同时提交的短连接的数目。

<!-- 限制当前接口中的每个接口的并发执行能力不超过10 -->
    <dubbo:service interface="com.abc.service.SomeService"
                   ref="zhifubaoService" actives="10"/>
    <!-- 限制当前接口中hello方法并发数量不超过10 -->
    <dubbo:service interface="com.abc.service.SomeService"
                   ref="weixinService">
        <dubbo:method name="hello" actives="10"/>
    </dubbo:service>

    <!-- 限制当前接口中的每个方法提交的请求不超过10 -->
    <dubbo:reference interface="com.abc.service.SomeService" id="zhifubaoService" actives="10"/>
    <!-- 限制当前接口中hello方法提交的连接数不超过10 -->
    <dubbo:reference interface="com.abc.service.SomeService" id="weixinService">
        <dubbo:method name="hello" actives="10"/>
    </dubbo:reference>

connections限流
connections限流与actives限流效果大体相同，同样可以设置在服务提供者端和服务消费者端。connnections无论设置在消费者端还是提供者端，无论是长连接还是短连接，其都表示最多支持的连接个数。

间接限流
上面所说的直接限流是通过直接限制服务的连接数来达到效率的目的；而间接限流则是通过一些非连接数量设置的间接手段来达到限流的目的。

延迟连接
延迟连接用于减少长连接数。只有当消费者端的调用发起时，才创建长连接，所以其是设置在消费者端的。由于其仅作用于长连接，所以其仅对于 Dubbo 服务暴露协议生效。

注意，该属性仅可设置在消费者端的dubbo:reference/与dubbo:consumer/标签 中，且也不能设置为方法级别。

原文链接：https://blog.csdn.net/m0_37135421/article/details/104476959