Dubbo配置——动态配置中心和服务治理

  配置中心(v2.7.0)在Dubbo中承担两个职责:node

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

  启用动态配置(以Zookeeper为例,可查看动态配置配置项详解):bash

<dubbo:config-center address="zookeeper://127.0.0.1:2181"/>
复制代码

  或者app

dubbo.config-center.address=zookeeper://127.0.0.1:2181
复制代码

  或者框架

ConfigCenterConfig configCenter = new ConfigCenterConfig();
configCenter.setAddress("zookeeper://127.0.0.1:2181");
复制代码
  • 为了兼容2.6.x版本配置,在使用Zookeeper做为注册中心,且没有显示配置配置中心的状况下,Dubbo框架会默认将此Zookeeper用做配置中心,但将只做服务治理用途。

外部化配置

  • 外部化配置目的之一是实现配置的集中式管理,这部分业界已经有不少成熟的专业配置系统如Apollo, Nacos等,Dubbo所作的主要是保证能配合这些系统正常工做。
  • 外部化配置和其余本地配置在内容和格式上并没有区别,能够简单理解为dubbo.properties的外部化存储,配置中心更适合将一些公共配置如注册中心、元数据中心配置等抽取以便作集中管理。
# 将注册中心地址、元数据中心地址等配置集中管理,能够作到统一环境、减小开发侧感知。
dubbo.registry.address=zookeeper://127.0.0.1:2181
dubbo.registry.simplified=true

dubbo.metadataReport.address=zookeeper://127.0.0.1:2181

dubbo.protocol.name=dubbo
dubbo.protocol.port=20880

dubbo.application.qos.port=33333
复制代码
  • 优先级

  外部化配置默认较本地配置有更高的优先级,所以这里配置的内容会覆盖本地配置值,你也可经过如下选项调整配置中心的优先级:spa

-Ddubbo.configCenter.highestPriority=false
复制代码
  • 做用域

  外部化配置有全局和应用两个级别,全局配置是全部应用共享的,应用级配置是由每一个应用本身维护且只对自身可见的。设计

  当前已支持的扩展实现有Zookeeper、Apollo。code

Zookeeper
<dubbo:config-center address="zookeeper://127.0.0.1:2181"/>
复制代码

  默认全部的配置都存储在/dubbo/config节点,具体节点结构图以下:router

  • namespace,用于不一样配置的环境隔离。
  • config,Dubbo约定的固定节点,不可更改,全部配置和服务治理规则都存储在此节点下。
  • dubbo/application,分别用来隔离全局配置、应用级别配置:dubbo是默认group值,application对应应用名
  • dubbo.properties,此节点的node value存储具体配置内容
Apollo
<dubbo:config-center protocol="apollo" address="127.0.0.1:2181"/>
复制代码

  Apollo中的一个核心概念是命名空间 - namespace(和上面zookeeper的namespace概念不一样),在这里全局和应用级别配置就是经过命名空间来区分的。   默认状况下,Dubbo会从名叫dubbo的命名空间中读取全局配置(<dubbo:config-center namespace="your namespace">)cdn

  而应用自有的配置,会从application命名空间读取

  • 注意:当前dubbo.properties是做为一个key存储在Apollo namespace中,为更好的适应Apollo的设计理念,在接下来的版本中可能会调整为

本身加载外部化配置
  • 所谓Dubbo对配置中心的支持,本质上就是把.properties从远程拉取到本地,而后和本地的配置作一次融合。理论上只要Dubbo框架能拿到须要的配置就能够正常的启动,它并不关心这些配置是本身加载到的仍是应用直接塞给它的,因此Dubbo还提供了如下API,让用户将本身组织好的配置塞给Dubbo框架(配置加载的过程是用户要完成的),这样Dubbo框架就再也不直接和Apollo或Zookeeper作读取配置交互。
// 应用自行加载配置
Map<String, String> dubboConfigurations = new HashMap<>();
dubboConfigurations.put("dubbo.registry.address", "zookeeper://127.0.0.1:2181");
dubboConfigurations.put("dubbo.registry.simplified", "true");

//将组织好的配置塞给Dubbo框架
ConfigCenterConfig configCenter = new ConfigCenterConfig();
configCenter.setExternalConfig(dubboConfigurations);
复制代码

服务治理

  • Zookeeper
  • 默认节点结构:
  • namespace,用于不一样配置的环境隔离。
  • config,Dubbo约定的固定节点,不可更改,全部配置和服务治理规则都存储在此节点下。
  • dubbo,全部服务治理规则都是全局性的,dubbo为默认节点
  • configurators/tag-router/condition-router,不一样的服务治理规则类型,node value存储具体规则内容

Apollo

  • 全部的服务治理规则都是全局性的,默认从公共命名空间dubbo读取和订阅:

不一样的规则以不一样的key后缀区分:

  • configurators,覆盖规则
  • tag-router,标签路由
  • condition-router,条件路由
相关文章
相关标签/搜索