Dubbo配置完全外部化实践，使用动态配置中心的注意事项

问题描述

近期开发项目，将Dubbo的配置全部外部化到动态配置中心。这里配置中心我使用的是Apollo。

@Configuration
public class DubboConfig {
  @Bean
  public ConfigCenterConfig configCenterConfig() {
    ConfigCenterConfig configCenterConfig = new ConfigCenterConfig();
    configCenterConfig.setAddress("apollo.xxxxx.com");
    configCenterConfig.setProtocol("apollo");
    configCenterConfig.setNamespace("dubbo");
    configCenterConfig.setGroup(null);
    return configCenterConfig;
  }
}

这里使用dubbo这个namespace。

其余配置全部配置在这个里面。

然后遇到一个大坑:

这里项目中定义了一个Service，也就是作为Provider提供了版本为provider.auth.version的服务。

package io.github.slankka.provider;

@Service(version = "${provider.auth.version:1.0}")
@Slf4j
public class AuthApiService implements IAuthApi

项目启动之后，注册到注册中心的版本是1.0。

在dubbo命名空间中定义了provider.auth.version=20000，但是启动还是1.0

问题分析

Apollo启动模式分为两种，一种是在 BeanDefinition阶段就将配置注入Spring容器内的Environment。另一种是在PostBeanFactory的时候启动。
而Dubbo启动的时候，所有的Service是ServiceBean的实例对应生成的代理类，所有的Reference是ReferenceBean的实例对应生成的代理类。
因此如果这里使用placeholder要被Spring识别，那么将必须选用第一种启动方式。

问题解决

在本地项目的application.properties中配置：

apollo.bootstrap.enabled = true
apollo.bootstrap.namespaces = application,dubbo

注意，这里apollo.bootstrap.namespaces 中加入了dubbo，这里有一个疑问：
之前配置Dubbo的时候不是定义了ConfigCenterConfig的namespace了吗，为什么还要定义一次。

 configCenterConfig.setNamespace("dubbo");

原因是：
Dubbo的ServiceBean在被Spring工厂构建出来的时候，就需要这个变量。但如果没有配置dubbo到apollo.bootstrap.namespaces，Spring会报错。
如果接口上写了默认版本，上例是1.0，则Spring不会报错，但是构建出来的对应ServiceBean中的版本将会是1.0，而Dubbo启动之后依然不会修改这个版本。

新的问题

为什么Dubbo的namespace中配置了这个变量，而且Dubbo在启动早起阶段就已经拉到了这些变量，但版本仍旧没有发生改变？

看一下Dubbo代码：

//package org.apache.dubbo.common.config;

public abstract class AbstractPrefixConfiguration implements Configuration {
    protected String id;
    protected String prefix;

    public AbstractPrefixConfiguration(String prefix, String id) {
        if (StringUtils.isNotEmpty(prefix) && !prefix.endsWith(".")) {
            this.prefix = prefix + ".";
        } else {
            this.prefix = prefix;
        }
        this.id = id;
    }

    @Override
    public Object getProperty(String key, Object defaultValue) {
        Object value = null;
        if (StringUtils.isNotEmpty(prefix)) {
            if (StringUtils.isNotEmpty(id)) {
                value = getInternalProperty(prefix + id + "." + key);
            }
            if (value == null) {
                value = getInternalProperty(prefix + key);
            }
        } else {
            value = getInternalProperty(key);
        }
        return value != null ? value : defaultValue;
    }
}

已知Dubbo是通过Configuration 的getProperty获取version等等这些属性，
这里可以看到用prefix + key的方式作为 property的名字来获取变量的值。
经过Debug发现，Dubbo的 AbstractPrefixConfiguration类的prefix正好是接口的FQCN，在本例中为：

AbstractPrefixConfiguration.prefix=dubbo.service.io.github.slankka.provider.IAuthApi.

那么key=version
因此可以推断出，Dubbo的外部化配置指定的Namespace中，如果要指定版本，且希望经过Dubbo的Environment处理，那么一定要用这种形式：

dubbo.service.io.github.slankka.provider.IAuthApi.version=20000

总结

如果使用placeholder的方式定义Service版本，那么根据习惯，要确保这些变量放在Spring启动阶段就能读到的地方。
如果要在Dubbo的namespace中定义，被Dubbo处理，那么要符合Dubbo的命令规则。dubbo.service.xxxxxxx.version等等这种形式。
如果使用placeholder的方式定义，但希望被Apollo直接处理，那么需要配置：

apollo.bootstrap.enabled = true
apollo.bootstrap.namespaces = application,dubbo

那么什么时候使用 placeholder什么时候使用 dubbo.service..version方式定义呢？

答案很显然是，如果多个接口都用共用同一个版本变量进行设置，用Apollo+Spring的方式进行处理。如果每一个接口都配置不同的版本，可以用Dubbo的方式定义。

进一步了解Dubbo和Apollo集成的遇到的有趣问题

解决Dubbo 2.7.3版本使用ConfigCenterConfig集成Apollo No Provider found的问题