dubbo高级特性

启动依赖检查

我们现在直接来启动我们的消费者：

它会报错。

 

 

 我们

再去直接运行我们的消费者就不会报错。

 我们也可以不在代码中去配置：

 实际工作中比较建议使用这种方式。

dubbo.reference.check是配置所有的reference里的service都是false。

dubbo.consumer.check是配置没有在注解reference里添加配置的服务是false。

dubbo.registry.check是配置当我们的服务者向注册中心去申请服务时失败的情况下配置仍然生效。

这个在启动时的配置参数方式我们基本上都不会去使用。

dubbo配置加载流程

配置优先级从上到下依次递减。

外部化我们2.7才开始支持。

 

 

我们之前是在xml文件里配置了check。

现在我们去配置一下参数：

 我们去启动一下：

 

报了我们的异常，这也就能够说明我们的-D参数配置优先级是大于我们的xml配置的。 

dubbo超时机制及集群容错机制

我们可以在xml里去配置我们的超时时间：

 我们现在去运行：

 

 

 我们还可以精确到方法：

 再次运行：

 

另外我们服务的消费方也可以做这样的一个设置：

 

 

 我们还可以去配置我们的重试次数：

 

 

 运行：

我们重试的是4次，但是我们设置的容错策略是一次失败策略，所以只会重试一次。

dubbo各协议及多协议配置

 dubbo协议也有缺点，所以我们dubbo是允许多协议的。

我们现在在api模块中再去创建一个接口：

然后我们去写它的实现类：

 

 另外因为我们使用Http协议，我们还要去配置相关依赖：

 同时我们还要去更改一下我们的配置类：

同样我们也要去修改我们服务者中的配置：

然后我们在controller中去引用它：

 

运行：

 

多注册中心及其配置

 

在网上我们可以看到有这么多的情况我们都涉及到多注册中心引用。

那我们应该怎么去配置呢？
 我们现在不只是用本地的zookeeper，同时我们还开启我们的虚拟机中的zookeeper:

 

 我们在xml中这样配置就可以了。