Dubbo常用配置文件分析

多版本支持

在Dubbo中配置不同版本的接口，会在zookeeper地址中有多个协议url的体现，具体内容如下：

dubbo%3A%2F%2F192.168.94.1%3A20880%2Fcom.yxk.IyxkHello%3Fanyhost%3Dtrue%26application%3Ddubbo-server%26dubbo%3D2.5.3%26interface%3Dcom.yxk.IyxkHello%26methods%3DsayHello%26owner%3Dyxk%26pid%3D4988%26revision%3D1.0.0%26side%3Dprovider%26timestamp%3D1536659809975%26version%3D1.0.0

dubbo%3A%2F%2F192.168.94.1%3A20880%2Fcom.yxk.IyxkHello2%3Fanyhost%3Dtrue%26application%3Ddubbo-server%26dubbo%3D2.5.3%26interface%3Dcom.yxk.IyxkHello%26methods%3DsayHello%26owner%3Dyxk%26pid%3D4988%26revision%3D1.0.1%26side%3Dprovider%26timestamp%3D1536659820796%26version%3D1.0.1

主机绑定

在发布一个Dubbo服务的时候，会生成一个dubbo://ip:port的协议地址，那么这个IP是根据什么生成的呢？大家可以在ServiceConfig.java代码中找到如下代码;可以发现，在生成绑定的主机的时候，会通过一层一层的判断，直到获取到合法的ip地址。

集群容错

什么是容错机制？容错机制指的是某种系统控制在一定范围内的一种允许或包容犯错情况的发生，举个简单例子，我们在电脑上运行一个程序，有时候会出现无响应的情况，然后系统会弹出一个提示框让我们选择，是立即结束还是继续等待，然后根据我们的选择执行对应的操作，这就是“容错”。

在分布式架构下，网络、硬件、应用都可能发生故障，由于各个服务之间可能存在依赖关系，如果一条链路中的其中一个节点出现故障，将会导致雪崩效应。为了减少某一个节点故障的影响范围，所以我们才需要去构建容错服务，来优雅的处理这种中断的响应结果。

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

1. failsafe失败安全，可以认为是把错误吞掉（记录日志）

2. failover(默认)   重试其他服务器； retries（2）

3. failfast快速失败， 失败以后立马报错

4. failback  失败后自动恢复。

5. forking  forks.设置并行数

6. broadcast  广播，任意一台报错，则执行的方法报错

配置方式如下，通过cluster方式，配置指定的容错方案

服务降级

降级的目的是为了保证核心服务可用

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

1.对一些非核心服务进行人工降级，在大促之前通过降级开关关闭哪些推荐内容、评价等对主流程没有影响的功能

2.故障降级，比如调用的远程服务挂了，网络故障、或者RPC服务返回异常。 那么可以直接降级，降级的方案比如设置默认值、采用兜底数据（系统推荐的行为广告挂了，可以提前准备静态页面做返回）等等

3.限流降级，在秒杀这种流量比较集中并且流量特别大的情况下，因为突发访问量特别大可能会导致系统支撑不了。这个时候可以采用限流来限制访问量。当达到阀值时，后续的请求被降级，比如进入排队页面，比如跳转到错误页（活动太火爆，稍后重试等）

dubbo的降级方式： Mock

实现步骤

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

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

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

配置优先级别

以timeout为例，显示了配置的查找顺序，其它retries, loadbalance等类似。

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

2.如果级别一样，则消费方优先，提供方次之。

其中，服务提供方配置，通过URL经由注册中心传递给消费方。

建议由服务提供方设置超时，因为一个方法需要执行多长时间，服务提供方更清楚，如果一个消费方同时引用多个服务，就不需要关心每个服务的超时设置。