1、启动检查

    为了保障服务的正常可用，Dubbo缺省会在启动时检查依赖的服务是否可用，不可用时会抛异常。

    此时，就出现一些问题，往往开发中是分模块开发，而服务消费者与服务提供者有连接关系，由于启动检查的原因，就会出现服务消费者永远不能测试的问题。

2 、 检 测 提 供 者 是 否 可 用 服 务 消 费 者 1 、 程 序 启 动 服 务 提 供 者

解决方案：

可以通过 check=false 关闭 ；是否开启启动检查主要是对于消费者

 

代码：

#配置dubbo服务消费者

dubbo:

 consumer:

  check: false  #关闭启动检查

 

2、多版本

在正式系统中，为保证系统可用性和更好的并发性，往往通过集群部署。

 

问题：如果提供者出现重大更新，如何对提供者升级部署？

解决方案：

灰度发布：当初出现新功能时，会先让一部分用户先使用新功能，用户反反馈没问题时，再将所有用户迁移至新功能，Dubbo也是支持灰度发布的，Dubbo提供了提供者多版本的支持，平滑处理项目功能升级部署。

 

消 费 者 集 群 消 奢 ^ 0 过 〕 消 费 者 ^ 远 程 调 用 远 程 调 用 提 供 者 集 群 檬 供 者 B 提 供 者 B

 

实现方法：

1、编写新的UserServce实现类，作为新版本代码

2、在暴露服务时，指定服务版本

通过在注解 @DubboService 中配置 version 设置版本号

Pubboservice(version = "2.ø.ø" ) public class userSeNiceImp12 implements user-Service {

3、消费者引用服务时，指定引用的服务版本

在注解 @DubboReFerence 中配置 version 设置版本号

@RestControIIer @Requestmapping("'user") public class User-controller { private UserService userService;

 

 

3、超时与重试

    服务消费者在带调用服务提供者的时候发生了阻塞、等待的情形，这个时候，服务消费者会一直等待下去。在某个峰值时刻，大量的请求都在同时请求服务消费者，会造成线程的大量堆积，势必会造成雪崩。

解决方案：

dubbo 利用超时机制来解决这个问题（使用timeout属性配置超时时间，默认值为1000，单位毫秒）

 

注意：

    若超时时间较短，当网络波动时就会请求失败，Dubbo通过重试机制避免此类问题的发生。

    服务消费者与服务提供者一共发生3次请求

 

Dubbo重试出现的问题：

    对于保存类的业务，由于可能的网络波动，服务消费者会向服务提供者发送3次请求，这时可能就会出现问题。

解决方案：

    在不需要重试机制的服务消费者 注解@DubboReference中设置retries属性的值，值为0，代表不进行重试。

 

 

4、负载均衡策略

    在集群部署时，Dubbo提供了4种负载均衡策略，帮助消费者找到最优提供者并调用。

 

Random ：按权重随机，默认值。按权重设置随机概率。

 

RoundRobin：按权重轮询

 

LeastActive：最少活跃调用数，相同活跃数的随机。

 

ConsistentHash：一致性Hash，相同参数的请求总是发到同一体提供者。

 

同样负载均衡指的是服务消费者，因此需要在服务消费者中配置，注解@DubboReference 中设置 locadbalance 属性 设置负载策略。