上一篇文章中我们介绍了dubbo与springBoot整合的基本功能：dubbo与springBoot整合（1）， 使用的方式是：引入 dubbo-spring-boot-starter 依赖包，在application.properties中配置dubbo的属性， 使用@EnableDubbo开启dubbo支持， 使用@Service暴露服务， 使用@Reference调用服务。但是有些功能，暂时不支持使用注解配置，如我们要设置具体到一个类中一个方法的超时时间，这时候@service注解就没法满足。
dubbo除了基本的RPC调用功能外，对于服务容错、服务降级、设置超时时间、重试等机制都有支持，下面我们就来介绍一下这些功能的使用。
1.首先我们先看一下，使用配置类，来配置dubbo服务
SpringBoot的配置类标识注解： @Configuration，新建配置类，注入响应的config ， 官方文档 dubbo API配置说明
这里我们可以看到，在配置文件中对应的配置，dubbo都提供了配置类和属性信息。
2、设置服务超时时间
设置超时时间，可以在服务消费者（consumer）处设置，也可以在服务提供者（provider）中设置。我们先来看一下在服务消费者总设置超时时间
我们先现在服务提供端，让返回数据前先休眠3s
2.1：服务消费者设置服务超时时间
在服务消费者端设置服务超时时间，一共有三种级别的设置方式：针对整个服务进行设置、针对某个类进行设置、针对某个类中的某个方法进行设置
首先看一下针对整个服务的超时时间配置：dubbo.consumer.timeout=2000 ， 即超时时间设置为2s
这时服务的响应为：
下面我们保留上面的配置不变，在@Reference注解中添加服务超时时间设置：
这时，再次请求服务：
这时可以看到，服务正常返回，也就是说我们在@Reference注解中配置的超时时间，优先级高于整个整个服务设置的超时时间。
dubbo还可以设置方法级别的超时时间，但注解无法满足该配置，这里先不做演示。
2.2 服务提供端设置服务超时时间
我们先去掉服务消费端的超时时间设置。这时候服务消费端的默认超时时间是1s，且是针对整个服务级别的设置。
服务提供端设置超时时间与消费端类似，可以设置整个服务的超时时间、针对某个类的超时时间、针对某个类的某个方法设置超时时间
设置服务端，针对整个服务的超时时间：dubbo.provider.timeout=4000
从页面发送请求：
这时可以看出，服务依然是请求超时，说明服务消费端的服务超时时间优先于服务提供端的超时时间设置。
下面我们再在服务提供端设置类界别的超时时间：@Service(timeout = 4000)
重新发送请求：
请求正常返回数据，说明在类界别设置的超时时间优先于服务界别的超时时间设置。
综合上面的四次超时时间这是可以看出来 配置的覆盖规则：
- 方法级配置别优于接口级别，即小Scope优先
- Consumer端配置 优于 Provider配置 优于 全局配置，
3、设置重试次数
失败自动切换，当出现失败，重试其它服务器，但重试会带来更长延迟。可通过 retries 属性来设置重试次数(不含第一次)。
我们让服务请求超时，看一下控制台输出：
从控制台的输出可以看出，服务被调用了三次，因为retries属性设置的值，不包含第一次调用，所以这里会出现三次调用。
retries属性还可以设置在@Reference注解中，这里不再演示：
4、多版本配置
对于一个接口，我们可能会有多个实现类；又或者我们随着需求的升级需要对原有功能进行升级，而新建一个接口的实现类，但是对于之前的功能有不能一下子直接废弃，这时就需要用到dubbo的多版本功能。
多版本功能是指，服务提供端针对一个服务提供了多种实现，每种实现方式指定一个唯一的版本信息，服务消费者在调用服务的时候，指定调用的服务版本即可。
服务提供者： @Service(version = "")
服务调用者： @Reference(version = "")
发送请求： 控制台输出
5、dubbo高可用
如果服务已经启动且服务消费端已经调用过服务提供端，这时候zookeeper注册中心宕机，dubbo仍可以正常调用服务。
原因：
- 监控之心宕机宕机，不影响服务的使用，只是丢失部分采样数据
- zookeeper宕机，注册中心仍能通过缓存提供服务列表查询，但不能注册新服务
- 注册中心对等集群，任意一台宕机后，将自动切换到另一台
- 注册中心全部宕机后，服务提供者和服务消费者仍能通过本地缓存通讯
- 服务提供者集群，任意一台宕机后，不影响使用
- 服务提全部宕机后，服务消费者将无法使用，并会无限次重连等待服务提供者恢复
dubbo还可以绕过服务注册中心，服务消费之直接连接服务提供者。
服务消费者，在@Reference注解中有一个属性，url="服务提供者的ip地址和服务端口号"
6、dubbo的负载均衡策略
如果服务提供端是一个集群，包含多个服务，那么我们可以指定服务消费端的负载均衡策略：
看一下官网对负载均衡策略配置的介绍：负载均衡策略可以在@Reference中指定也可以在consumer配置中指定，这里遵循的原则是Reference的配置优先级大于consumer的配置。 如果不指定负载均衡策略，则默认是random 随机轮询。
dubbo中的几个负载均衡策略：
- random ： 随机策略，按照权重设置随机概率，如果一个服务的权重越大，服务调用到这台机器的概率也就越大。如在集群中一台机器的权重比为 4/7 ， 那么每次服务调用到它的概率为4/7。
- roundrobin ： 轮询策略，按照权重设置轮询比率，如一个服务的权重是4/7， 那么每七次调用中，就一定会有四次调用该服务。
- leastactive ：最少活跃调用数，相同或活跃数的随机，活跃数指调用前后计数差。使慢的提供者收到更少的请求，因为越慢的提供者的调用前后计数差会越大。
7、服务降级
服务降级就是当服务器压力激增的情况下，根据实际业务情况及流量，对一些服务和页面有策略的不处理或换种简单的方式处理，从而释放服务器资源以保证核心交易正常、高效运作。
dubbo实现服务降级的多种方式：
一、 在dubbo管理控制台配置服务降级（屏蔽和容错）
- 屏蔽： mock=force:return+null ，表示消费方对该服务的方法调用都直接返回null，即不发起远程调用。 用来屏蔽不重要的服务不可用时对服务消费端的影响。
- 容错： mock=fail:return+null ， 表示消费方对服务的方法调用在失败后，再返回null， 不抛异常。 用来容忍不重要服务不稳定时对服务消费端的影响。
屏蔽和容错的一个最本质的区别是： 屏蔽是直接不调用服务提供端，而直接返回null ； 而容错是调用服务提供端出错时，不抛异常，返回null值。
二、 在服务提供端的@Reference 注解中配置mock属性
使用注解配置mock属性时，mock值比较灵活，如：
- @Reference(mock="return null")
- @Reference(mock="return 简单值")
- @Reference(mock="force:return null")
三、使用java代码动态写入配置中心：
四、整合hystrix， 即SpringCloud中的服务容错：
这里的操作与SpringCloud中的服务容错相同，可以参考SpringCloud中的hystrix介绍： SpringCloud Hystrix
到此，dubbo的一些常用的基本功能介绍完毕，后面我们会着重看一下dubbo中的一些服务的实现源码。
