关于外部化存储，我们的对接模型上是将dubbo.properties作为一个整体考虑的，比如
1.
对应到Zookeeper，是一个`/dubbo/config/{全局或应用名}/dubbo.properties`的节点，而节点下存储的是完整的.properties配置
```properties
dubbo.registry.address=zookeeper://127.0.0.1:2181
dubbo.metadataReport.address=zookeeper://127.0.0.1:2181
dubbo.protocol.port=-1
dubbo.consumer.timeout=600
```
2.
对应到Apollo，我们从ZK的角度映射过来，只考虑`{全局或应用名}/dubbo.properties`的映射，`全局或应用名`对应到Apollo的`global
namespace或者application namespace`，`dubbo.properties`对应到apoll的`key`。
但是，我们发现，这样的模型和Apollo的组织并不是很匹配，Apollo倾向于将一个namespace下的所有配置组织为一个.properties或其他格式的文件
http://106.12.25.204:8070/config.html?#/appid=dubbo-configcenter-apollo
我们可以考虑做如下改造：继续保持在Dubbo框架侧将`dubbo.properties`作为一个整体来操作和读取，而将`dubbo.properties`映射到Apollo时，不在作为一个namespace中的key，而是作为一个namespace将`dubbo.properties`中的配置内容分别作为NS中的key。看起来Apollo提供的ConfigService.getConfigFile能满足读取要求。
[ 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]
