在前面的学习中，我们已经简单的了解和学习了一下dubbo的基本使用方式以及注册中心的有效用途；我们知道dubbo并不是一定需要依赖注册中心的；

那么在这一节中，我们对dubbo的配置文件做一个基本的记录；

Dubbo的常见配置

1、 启动检查配置

2、 版本兼容配置

3、 服务只订阅、服务只发布配置

4、 集群容错配置

5、 负载均衡策略配置

6、 服务超时配置

7、 异步调用配置

8、 多协议支持配置

9、 多注册中心配置

1、 启动检查配置

启动检查配置是指的在服务启动时，是否检查所需调用的服务是否有启动，可被正常调用；比如商品服务调用了订单服务，在启动商品服务的时候，是否检查订单服务有正常启动。

通常情况下我们会将此配置关闭，也就是启动不检查；在总结这个配置时，我发现这个配置其实和Spring中的懒加载和立即加载挺相似的；Spring默认采用立即加载，有助于排查项目中存在的一些问题；

而dubbo这里我们可以配置为懒加载，在使用的时候才知道服务能否被正常调用；

dubbo中我们可以在配置文件中配置dubbo: consumer: check: false来设置关闭启动检查，也可以通过xml来配置<dubbo:refrence check=true>；

2、 版本兼容配置

有时候，我们发现线上的版本有缺陷、或者需要升级服务，这时候需要利用DUBBO多版本的特性对服务进行升级。

对dubbo稍有了解的朋友会知道，dubbo对外暴露接口，是针对于接口级别的，所以我们在这里配置的版本兼容，也是针对于接口级别的；

我们可以使用xml申明式，也可以使用注解式；每个接口都应定义版本号，为后续不兼容升级提供可能，如：<dubbo:service interface="com.xxx.XxxService" version="1.0" /> ， 或者使用@Service(version = "1.0")

建议版本号编写两位即可；

3、 服务只订阅、服务只发布配置；

这里最常见的就是网关服务和基础组件服务了；网关服务可以直接通过访问控制层调用，不需要项目自身的服务调用，所以它只需要订阅注册中心的服务即可，而不需要将自己发布到注册中心；

同理，基础服务组件类似于短信服务、全文检索等基础组件，只需要对外暴露API提供给其它服务调用即可，不需要从注册中心订阅其它服务地址；所以这一类的服务就可以只发布不订阅；

只订阅不发布配置文件：dubbo:registry:register: false

只发布不订阅配置文件：dubbo:provider:register: false

4、 集群容错配置

Dubbo提供了多种容错机制，其默认的容错机制为Failover Cluster；

Failover Cluster：失败重试；

当服务消费方调用服务提供者失败后自动切换到其他服务提供者服务器进行重试。这通常用于读操作或者具有幂等的写操作，需要注意的是重试会带来更长延迟。可通过 retries="2" 来设置重试次数（不含第一次）

失败重试我们可以配置重试次数作为全局配置，也可以为某一个接口单独做配置重试次数。Dubbo默认的重试次数为2，也就是最坏结果情况下，一共会请求3次；

dubbo:consumer:cluster: failfast      #集群容错方式，快速失败只发一次请求

Failfast Cluster：快速失败

当服务消费方调用服务提供者失败后，立即报错，也就是只调用一次。通常这种模式用于非幂等性的写操作。

Failback Cluster：失败自动恢复

当服务消费端用服务出现异常后，在后台记录失败的请求，并按照一定的策略后期再进行重试。这种模式通常用于消息通知操作。

Forking Cluster：并行调用

当消费方调用一个接口方法后，Dubbo Client会并行调用多个服务提供者的服务，只要一个成功即返回。这种模式通常用于实时性要求较高的读操作，但需要浪费更多服务资源。可通过 forks="2" 来设置最大并行数。

Broadcast Cluster：广播调用

当消费者调用一个接口方法后，Dubbo Client会逐个调用所有服务提供者，任意一台调用异常则这次调用就标志失败。这种模式通常用于通知所有提供者更新缓存或日志等本地资源信息。

5、 负载均衡策略

负载均衡策略相比较而言应该是比较好认识和理解的，在很多地方都有负载均衡策略，最常见的比如nginx中的负载均衡策略；dubbo中的负载均衡策略和nginx中的还是比较相似的；

random：随机调用

按照概率设置权重，比较均匀，并且可以动态调节提供者的权重

roundrobin: 轮询调用

根据注册中心中注册的节点数据轮询调用；

leastActive LoadBalance：最少活跃调用数，响应时间断服务优先调用。

如果每个服务的活跃数相同，则随机调用，在每个服务提供者中维护一个活跃请求计数器，用来记录当前处理的请求数。当活跃计数器值越大，说明当前待处理的请求数越多，服务压力越大，对新的请求就可以分发到活跃数较小的节点上；同理，当活跃计数器越小，说明响应速度越快，可以处理更多的请求；

在解决分布式系统中，负载均衡的问题可以使用Hash算法让固定的一部分请求落到同一台服务器上，这样每台服务器固定处理一部分请求（并维护这些请求的信息），起到负载均衡的作用。一致性Hash具有良好的单调性、分散性及平衡性；

6、 服务超时配置

在很多场景中，我们希望服务请求可以在指定时间内完成，指定时间内未完成立即失败，这样不需要用户花太长时间等待服务响应；

在dubbo中很有的解决了这一点，dubbo中可以对每个请求指定超时时间，不单单是消费端，还可以在服务端做限制；

Dubbo中默认的超时时间是1秒钟，但是正常的服务调用1秒钟是远远不够的，这时候我们可以配置全局的服务超时时间；

消费端全局配置：<dubbo:consumer timeout="1000"></dubbo:consumer>

服务端全局配置：<dubbo:provider timeout="1000"></dubbo:provider>

还可以通过yml文件设置

dubbo:consumer:timeout: 60000  # 1分钟

同时，我们还可以针对某些接口单独的进行配置，比如有的接口可能需要处理大量的数据，我们可以为接口单独配置超时时间；

@Service(timeout = 120000)

超时是针对消费端还是服务端？

如果是争对消费端，那么当消费端发起一次请求后，如果在规定时间内未得到服务端的响应则直接返回超时异常，但服务端的代码依然在执行。

如果是争取服务端，那么当消费端发起一次请求后，一直等待服务端的响应，服务端在方法执行到指定时间后如果未执行完，此时返回一个超时异常给到消费端。

dubbo的超时是争对客户端的，由于是一种NIO模式，消费端发起请求后得到一个ResponseFuture，然后消费端一直轮询这个ResponseFuture直至超时或者收到服务端的返回结果。虽然超时了，但仅仅是消费端不再等待服务端的反馈并不代表此时服务端也停止了执行。

7、 异步调用配置

一般来说，异步调用都是针对消费端，我们可以为消费端开启异步调用；异步调用可以针对服务，也可以针对具体的接口。

针对当前服务: <dubbo:consumer async="true"/>

针对当前接口： <dubbo:reference interface="com.demo.user.api.service.UserService" id="userService" async="ture"/>

或者通过注解也可以实现；

8、 多协议支持

Dubbo支持多种协议，默认采用的是dubbo协议；在一个服务中，允许配置多种协议支持，常见的协议有jetty、hessian、http等协议；通常情况下我们使用默认的dubbo协议即可；