> 所以，apollo的模型是倾向于把namespace类比为properties文件，包含了逻辑上的一组配置，同时对于公共配置，支持通过界面直观的操作单个/多个配置的自定义。
>按照目前dubbo的组织方式（把dubbo相关配置作为一个配置项管理）也能实现上述功能，不过对于用户使用（配置或覆盖）可能就不那么直观了
@nobodyiam 我想我们已经就`Apollo的模型`和`Dubbo当前的抽象模型`，这两个点上的理解达成了一致。
> 鉴于dubbo需要接入更多配置中心，所以在模型上做一层抽象是合理的，不过也希望能讨论下是否有可能使这个抽象也能更好地支持类似apollo这样的模型。
这是我开启这个issue讨论的原因之一，我们需要让Dubbo尽量遵循每个配置中心的原生概念。
> 2. 如果需要获取dubbo这个namespace所有的配置
> ```java
> ConfigService.getConfigFile("dubbo",
> ConfigFileFormat.Properties).getContent();
> //以properties格式返回所有配置
> //dubbo.registry.address=zookeeper\://1.2.3.4\:2181
> //dubbo.consumer.timeout=5000
> ```
ConfigService.getAppConfig()对应到ConfigService.getConfigFile("application",
ConfigFileFormat.Properties).getContent();
是这样的吗？
[ Full content available at:
https://github.com/apache/incubator-dubbo/issues/3266 ]
This message was relayed via gitbox.apache.org for
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
