Dubbo-深入配置 - 码农教程

　　属性配置覆盖规则：消费端优先于提供端，方法优先于接口配置，接口优先于全局配置

　　负载均衡、服务降级，一般采用控制台动态控制。

1. 启动检查：check="false"

　　正常情况下，启动的时候会进行一些检查，如果检查到某些异常，会进行报错，可以使用配置将启动检查关闭，在真正调用的时候，在进行检查

<dubbo:reference interface="com.foo.BarService" check="false" />　　//当前服务没有提供者时，不进行检查
<dubbo:consumer check="false" />　　　　　　　　　　　　　　　　　　　　　//所有服务没有提供者时，不进行检查
<dubbo:registry check="false" />　　　　　　　　　　　　　　　　　　　　　//注册中心没启动，不进行检查

2. 超时时间：timeout="1"

　　默认1000毫秒

    <dubbo:reference interface="com.ll.service.UserService" id="userService" timeout="1000" >
        <dubbo:method name="getUserAddressList" timeout="2000" />
    </dubbo:reference>
　　<dubbo:consumer timeout="5000" />

3. 重试次数：

　　在幂等【查询、删除、修改】情况下可以设置重试次数（执行多次结果一样）

　　在非幂【增加】等情况下不能设置重试次数（不能执行多次）

    <dubbo:reference interface="com.ll.service.UserService" id="userService" retries="2" >
        <dubbo:method name="getUserAddressList" retries="1" />
    </dubbo:reference>
　　<dubbo:consumer check="false" retries="3" />

4. 多版本：可以实现灰度发布

　　当一个接口实现，出现不兼容升级时，可以用版本号过渡，版本号不同的服务相互间不引用。

　　可以按照以下的步骤进行版本迁移：

　　　　0. 在低压力时间段，先升级一半提供者为新版本

　　　　1. 再将所有消费者升级为新版本

　　　　2. 然后将剩下的一半提供者升级为新版本

<dubbo:service interface="com.foo.BarService" version="1.0.0" />    //老版本服务提供者配置
<dubbo:service interface="com.foo.BarService" version="2.0.0" />    //新版本服务提供者配置

<dubbo:reference id="barService" interface="com.foo.BarService" version="1.0.0" />    //老版本服务消费者配置
<dubbo:reference id="barService" interface="com.foo.BarService" version="2.0.0" />    //新版本服务消费者配置

<dubbo:reference id="barService" interface="com.foo.BarService" version="*" />        //如果不需要区分版本，可以用*配置

5. 本地存根：

　　远程服务后，客户端通常只剩下接口，而实现全在服务器端，但提供方有些时候想在客户端也执行部分逻辑，比如：做 ThreadLocal 缓存，提前验证参数，调用失败后伪造容错数据等等，
　　此时就需要在 API 中带上 Stub，客户端生成 Proxy 实例，会把 Proxy 通过构造函数传给 Stub，然后把 Stub 暴露给用户，Stub 可以决定要不要去调 Proxy。
　　如果条件满足，在去调用远程接口，不满足就不去调用

　　》Stub 的实现：

public class UserServiceStub implements UserService {
    private final UserService userService;

    // 构造函数传入真正的远程代理对象
    public UserServiceStub(UserService userService) {
        this.userService = userService;
    }
    // 此代码在客户端执行, 你可以在客户端做ThreadLocal本地缓存，或预先验证参数是否合法，等等
    @Override
    public List<UserAddress> getUserAddressList(String userId) {
        return StringUtils.isEmpty(userId)  ? userService.getUserAddressList(userId) : null ;
    }
}

　　》在spring dubbo配置文件中进行配置：

    <dubbo:reference interface="com.ll.service.UserService" id="userService" stub="com.ll.service.impl.UserServiceStub" />

6. 高可用：zookeeper宕机与dubbo直连

　　zookeeper宕机：注册中心全部宕机后，服务提供者和服务消费者仍可以通过本地缓存通讯。当调过一次提供者后，提供者所在的主机信息，方法等都有缓存

　　》dubbo直连：

@Reference(url = "192.168.28.219:2181")　　//注解

<dubbo:reference interface="com.ll.service.UserService" id="userService" url="192.168.28.219:2181">　　//配置文件

7. 负载均衡机制：

　　在集群负载均衡时，Dubbo 提供了多种均衡策略，默认为 random 随机调用。

　　》Random LoadBalance
　　　　随机，按权重设置随机概率。
　　　　在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。
　　》RoundRobin LoadBalance
　　　　轮循，按公约后的权重设置轮循比率。
　　　　存在慢的提供者累积请求的问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。
　　》LeastActive LoadBalance
　　　　最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差。
　　　　使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。
　　》ConsistentHash LoadBalance
　　　　一致性 Hash，相同参数的请求总是发到同一提供者。
　　　　当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。算法参见：http://en.wikipedia.org/wiki/Consistent_hashing
　　　　缺省只对第一个参数 Hash，如果要修改，请配置 <dubbo:parameter key="hash.arguments" value="0,1" />
　　　　缺省用 160 份虚拟节点，如果要修改，请配置 <dubbo:parameter key="hash.nodes" value="320" />

</dubbo:reference>
<!--服务端服务级别-->
<dubbo:service interface="..." loadbalance="roundrobin" />
<!--服务端方法级别-->
<dubbo:service interface="...">
    <dubbo:method name="..." loadbalance="roundrobin"/>
</dubbo:service>

<!--客户端服务级别-->
<dubbo:reference interface="..." loadbalance="roundrobin" />
<!--客户端方法级别-->
<dubbo:reference interface="...">
<!--全局-->
<dubbo:consumer check="false" loadbalance="roundrobin" />

8. 服务降级：

　　当服务器压力剧增的情况下，根据实际业务情况及流量，对一些服务和页面有策略的不处理或换种简单的方式处理，从而释放服务器资源以保证核心交易正常运作或高效运作。
　　可以通过服务降级功能临时屏蔽某个出错的非关键服务，并定义降级后的返回策略。
　　　　》mock=force:return+null 表示消费方对该服务的方法调用都直接返回 null 值，不发起远程调用。用来屏蔽不重要服务不可用时对调用方的影响。
　　　　》mock=fail:return+null 表示消费方对该服务的方法调用在失败后，再返回 null 值，不抛异常。用来容忍不重要服务不稳定时对调用方的影响。

9. 服务容错：

　　在集群调用失败时，Dubbo 提供了多种容错方案，缺省为 failover 重试。
　　》集群容错模式
　　　　Failover Cluster失败自动切换，当出现失败，重试其它服务器。通常用于读操作，但重试会带来更长延迟。可通过 retries="2" 来设置重试次数(不含第一次)。
　　　　Failfast Cluster快速失败，只发起一次调用，失败立即报错。通常用于非幂等性的写操作，比如新增记录。
　　　　Failsafe Cluster失败安全，出现异常时，直接忽略。通常用于写入审计日志等操作。
　　　　Failback Cluster失败自动恢复，后台记录失败请求，定时重发。通常用于消息通知操作。
　　　　Forking Cluster并行调用多个服务器，只要一个成功即返回。通常用于实时性要求较高的读操作，但需要浪费更多服务资源。可通过 forks="2" 来设置最大并行数。
　　　　Broadcast Cluster广播调用所有提供者，逐个调用，任意一台报错则报错 [2]。通常用于通知所有提供者更新缓存或日志等本地资源信息。

//集群模式配置
<dubbo:service cluster="failsafe" />　　<dubbo:reference cluster="failsafe" />

　　在实际的工作中通过整合"hystrix"进行容错：

(1). 导入依赖包：

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
    <version>2.1.2.RELEASE</version>
</dependency>

(2). 然后在Application类上增加@EnableHystrix来启用hystrix starter：

@SpringBootApplication
@EnableHystrix　　//开启服务容错
public class ProviderApplication {

(3). 配置Provider端:

在Dubbo的Provider上增加@HystrixCommand配置，这样子调用就会经过Hystrix代理。

@HystrixProperty
public String sayWord(String name) {

(4). 配置Consumer端:

对于Consumer端，则可以增加一层method调用，并在method上配置@HystrixCommand。当调用出错时，会走到fallbackMethod = "reliable"的调用里。

@HystrixCommand(fallbackMethod = "hello")　　//出错了，调用hello方法
public String sayHello(String name) {

集群模式配置

原文地址：https://www.cnblogs.com/luliang888/p/11216464.html