Closed bestK closed 3 months ago
有几个问题点要确认:
如果是想支持全量配置导出导入,这个已经有对应的计划,待开发。参考#89
1.截图可能有误解,里面的配置文件是我随便写的,事跟随现有格式的 2.是的 3.我也是想着前端加个全量导出的按钮,这样就不用一个个命名空间的导入导出了
全量导出导入是合理的需要,后面有计划支持。
这里不涉及调整文件格式,那么我理解就和全量导出导入无关。
那就是这里pr主要只是想在导出时把命名空间写入manifest;导入时支持从manifest获取并创建命名空间,把配置导入到对应命名空间中是吗? 主要为了节省手动创建命名空间并切换命名空间的工作?
全量导出导入是合理的需要,后面有计划支持。
这里不涉及调整文件格式,那么我理解就和全量导出导入无关。
那就是这里pr主要只是想在导出时把命名空间写入manifest;导入时支持从manifest获取并创建命名空间,把配置导入到对应命名空间中是吗? 主要为了节省手动创建命名空间并切换命名空间的工作?
是的
如果是为了节省手动创建命名空间并切换命名空间的工作,本来加上这个功能也算是可接受的,不过这部分逻辑会和现有的功能有冲突。而这个功能似乎也是通用的,不需要在特定命名空间生效。
新增加这个功能的优点:
缺点:
综上所述:增加这个功能的优点不大,缺点比较多,以目前的方式引入这个功能可能不太合适。
这个简单说下我们的解决思路,可以做个参考,就是会有点限制,毕竟 nacos 支持的类型比较多,我这边可以贡献个 go 写的(rust 不太熟😂):
这个简单说下我们的解决思路,可以做个参考,就是会有点限制,毕竟 nacos 支持的类型比较多,我这边可以贡献个 go 写的(rust 不太熟😂):
- 导出的格式使用properties,这样可以同时支持 Apollo及 nacos,也能用于自建的 spring cloud config
- 命名使用 namespaceId _groupid _dataid 的方式,这样就可以支持apllo 和 nacos 的解析,这两个的结构层次是一致的
- 使用全量替换的方式,这样可以避免出错
这个规则也需要二次加工后才能于nacos兼容。如果需要二次加工的话,使用二进程格式也没有问题。
另外文件的规则也可能出现歧义、冲突,比如groupId或dataId中有'_'解析时可能会有问题。
// 当 tenant 为 all 时,根据 tenant 打包配置文件,并导出 namespace 到 manifest http://127.0.0.1:10848/rnacos/api/console/config/download?dataParam=&groupParam=&tenant=all&pageNo=1&pageSize=20
在原有导入逻辑中判断是否压缩包中存在 manifest ,如果存在,认为是根据
namespace
导入,会先尝试创建对应的 namespace 之后再导入到对应的 namespace