dubbo高级特性

服务分组及其配置

我们再来创建一个实现类：

 接下来我们在xml中去进行配置：

 现在我们去运行看是否会有错误呢？

 我们有两个服务实现类，那运行的时候到底执行哪个呢？

 但是我们想的是可以指定执行哪个实现类，这种随机的肯定不好。

所以就应用到了我们的服务分组：

 同时我们的消费者方也需要去进行配置：

 我们去运行一下：

这样一个服务多个实现，我们就可以指定让服务实现哪个实现类了。

服务多版本化及其配置

我们提供者如果配置了版本号，那么我们的消费者也需要配置版本号，不然无法正常启动：

管控台dubbo-ops的编译安装

我们可以在这个文件中看到我们的配置中心数据。但是我们用的是本地的zookeeper，所以我们这里不需要去更改。

 然后我们去运行：

我们就能登录到这个网站了。

动态配置中心及配置外部化

• 简介：介绍动态配置中心及配置外部化

• 为什么要使用动态配置中心？

• 动态配置中心的责职

  外部化配置。启动配置的集中式存储 （简单理解为dubbo.properties的外部化存储）。​ 服务治理。服务治理规则的存储与通知。

• 如何使用?

  • 在dubbo-ops 进行配置信息配置
  • 在项目里使用

• 配置中心中的配置的作用域

  如果全局配置跟应用级别均配置了相同的信息，这个时候以应用级别的为准

我们可以看到我们的外部化配置。

 那这种方式我们的消费者和生产者怎么进行配置呢？

我们之前配置了注册中心地址，那么同样的我们的protocol也可以去进行在外部配置：

然后就可以运行我们的提供者了。 

 同理我们的消费者的地址标签也要更改了：

 我们再去创建一个外部化配置，精确到具体服务，我们看看和全局哪个优先级更高呢？

我们这里也可以去配置别的zookeeper地址，我没有别的就注册到这个了。

 我们的应用级别是大于全局配置的。

然后我们以后就可以进行这样的外部化的方式进行配置了。

元数据中心及服务测试

我们先需要去加入我们的zookeeper的相关元数据中心的配置：

 在提供者的xml中加入。

 我们把之前的外部化配置中加上元数据化配置：

 然后现在我们来进行服务测试：

但是我们这里的测试是有一点Bug的，所以我们就不演示了。

到此我们的dubbo基础就学完了。