Dubbo配置问题-2

目录

配置优先级别 1.dubbo的多版本支持 2.主机绑定过程分析 3.集群容错 4.服务降级

配置的优先级别是什么呢?

客户端的配置优先于服务端 1.方法级优先，接口级次之，全局配置再次之。 2.如果级别一样，则消费方优先，提供方次之。

其中，服务提供方配置，通过URL经由注册中心传递给消费方. 关于哪些配置由服务端配置哪些配置由客户端配置一般看谁更清楚业务吧,比如超时配置一般服务端设置,因为一个方法需要执行多长时间，服务提供方更清楚，如果一个消费方同时引用多个服务，就不需要关心每个服务的超时设置。

1.多版本支持

当服务提供者提供的服务接口出现不兼容升级时,可以设置版本号,使用多个版本号(version)进行过渡。 可以按照以下的步骤进行版本迁移：

• 在低压力时间段，先升级一半提供者为新版本
• 再将所有消费者升级为新版本
• 然后将剩下的一半提供者升级为新版本

如图,我们在服务端配置了俩实现类,并均对外提供服务

反映到Zk注册中心,看一下provider

发现服务已经注册上去,这里我们在客户端进行配置看看有没有用,结果如下,显然有用.

<dubbo:reference id="cliRes" interface="com.zyh.dubbo.ApiInterface" check="false" version="1.0.0"/>

<dubbo:reference id="cliRes" interface="com.zyh.dubbo.ApiInterface" check="false" version="1.0.1"/>

ps:对于配置了版本号的服务,我们在客户端一定要指定版本号哦.否则就是ERROR

2.主机绑定过程分析

我们服务端在发布url时对于ip的获取经历了许多过程. 具体在源码中体现.在dubbo-config模块的ServiceConfig源码中有一列的判断和尝试.即在生成绑定的主机的时候，会通过一层一层的判断和不断的尝试，直到获取到合法的ip地址。|

1. NetUtils.isInvalidLocalHost(host)， 从配置文件中获取st

2. 尝试从网卡拿host = InetAddress.*getLocalHost*().getHostAddress();

3. 尝试利用socket连接注册中心得到地址
try {
    SocketAddress addr = new InetSocketAddress(registryURL.getHost(), registryURL.getPort());
    socket.connect(addr, 1000);
    host = socket.getLocalAddress().getHostAddress();
    break;
} finally {
    try {
        socket.close();
    } catch (Throwable e) {}
}
4. 最后拿不到可能会从本地网卡拿
public static string getLocalHost () {
InetAddress address = getLod lAddress (); 
return address = null ? LOCALHOST : address. getHostAddress ();
}

3.集群容错

什么是容错机制？ 容错机制指的是某种系统控制在一定范围内的一种允许或包容犯错情况的发生，举个简单例子，我们在电脑上运行一个程序，有时候会出现无响应的情况，然后系统会弹出一个提示框让我们选择，是立即结束还是继续等待，然后根据我们的选择执行对应的操作，这就是“容错”。 在分布式架构下，网络、硬件、应用都可能发生故障，由于各个服务之间可能存在依赖关系，如果一条链路中的其中一个节点出现故障，将会导致雪崩效应。为了减少某一个节点故障的影响范围，所以我们才需要去构建容错服务，来优雅的处理这种中断的响应结果.

Dubbo提供了6种容错机制，官方文档

• 1.failsafe 失败安全，出现异常时，直接忽略。通常用于写入审计日志等操作。
• 2.failover(默认) 失败自动切换，当出现失败，重试其它服务器。通常用于读操作，但重试会带来更长延迟。可通过 retries="2" 来设置重试次数(不含第一次)。一般用于查询操作. 重试次数配置如下：<dubbo:service retries="2" />或<dubbo:reference retries="2" /> 或<dubbo:reference><dubbo:method name="findFoo" retries="2" /></dubbo:reference>
• 3.failfast 快速失败，只发起一次调用，失败立即报错。通常用于非幂等性的写操作，比如新增记录。一般适用于增删改这样的事务操作.
• 4.failback 失败自动恢复，后台记录失败请求，定时重发。通常用于消息通知操作或者增删改这样的事务操作。
• 5.forking forks. 设置并行数, 并行调用多个服务器，只要一个成功即返回。通常用于实时性要求较高的读操作，但需要浪费更多服务资源。可通过 forks="2" 来设置最大并行数。
• 6.broadcast 广播，广播调用所有提供者，逐个调用，任意一台报错则报错通常用于通知所有提供者更新缓存或日志等本地资源信息。

配置方法,通过cluster方式，配置指定的容错方案

按照以下示例在服务提供方和消费方配置集群模式

<dubbo:service cluster="failsafe" />
或
<dubbo:reference cluster="failsafe" />

4.服务降级

降级措施配置: Mock

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

这里提供一个示例,我们在客户端(服务端也可配置)对ApiInterface(降级类要实现这个接口)的接口调用进行配置一个超时降级措施,仅需配置引用方法的降级类就好. 超时调用类

public class AppMock implements ApiInterface {
    @Override
    public String returnName(String s) {
        return "系统繁忙,请稍后再试: "+s;
    }
}

配置

<dubbo:reference id="cliRes" interface="com.zyh.dubbo.ApiInterface" check="false"
     mock="com.zyh.dubbo.AppMock" version="1.0.0" timeout="1"/>

这里配置了超时时间为1ms,超过1ms或者系统直接宕机了不管用了,dubbo服务端没返回处理结果我们这里就直接调用配置好的降级类.

ps:注意这里同时配置容错和降级可以能会出现冲突问题.比如failsafe的吞错误会使降级得不到错误降级信号.