nacos-group / r-nacos

Nacos server re-implemented in Rust.
https://r-nacos.github.io/docs/
Apache License 2.0
840 stars 93 forks source link

feat:根据 namespace 导入导出 #106

Closed bestK closed 3 months ago

bestK commented 4 months ago

// 当 tenant 为 all 时,根据 tenant 打包配置文件,并导出 namespace 到 manifest http://127.0.0.1:10848/rnacos/api/console/config/download?dataParam=&groupParam=&tenant=all&pageNo=1&pageSize=20

image

在原有导入逻辑中判断是否压缩包中存在 manifest ,如果存在,认为是根据 namespace 导入,会先尝试创建对应的 namespace 之后再导入到对应的 namespace

heqingpan commented 4 months ago

有几个问题点要确认:

  1. 这个文件格式是自定义的,还是和nacos兼容的?
  2. 这个功能对应需求是想让r-nacos支持全量配置的导出导入是吗?
  3. 通过指定的命名空间触发全量导出导入,这个方式用户很难明确感知。可能通过增加独立新按键触发方式更合理。

如果是想支持全量配置导出导入,这个已经有对应的计划,待开发。参考#89

bestK commented 4 months ago

1.截图可能有误解,里面的配置文件是我随便写的,事跟随现有格式的 2.是的 3.我也是想着前端加个全量导出的按钮,这样就不用一个个命名空间的导入导出了

heqingpan commented 4 months ago

全量导出导入是合理的需要,后面有计划支持。

这里不涉及调整文件格式,那么我理解就和全量导出导入无关。

那就是这里pr主要只是想在导出时把命名空间写入manifest;导入时支持从manifest获取并创建命名空间,把配置导入到对应命名空间中是吗? 主要为了节省手动创建命名空间并切换命名空间的工作?

bestK commented 4 months ago

全量导出导入是合理的需要,后面有计划支持。

这里不涉及调整文件格式,那么我理解就和全量导出导入无关。

那就是这里pr主要只是想在导出时把命名空间写入manifest;导入时支持从manifest获取并创建命名空间,把配置导入到对应命名空间中是吗? 主要为了节省手动创建命名空间并切换命名空间的工作?

是的

heqingpan commented 4 months ago

如果是为了节省手动创建命名空间并切换命名空间的工作,本来加上这个功能也算是可接受的,不过这部分逻辑会和现有的功能有冲突。而这个功能似乎也是通用的,不需要在特定命名空间生效。

新增加这个功能的优点:

  1. 导入配置时节省手动创建命名空间并切换命名空间的工作。

缺点:

  1. 目前导入是导入到当前用户操作的命名空间,这个功能支持把一个命名空间的数据导入到另一个命名空间当做配置初始化。比如开发环境的配置导入预发环境、预发环境的配置导入到线上环境。 如果导出导入都绑定命名空间的话,那么就无法支持把配置导入到另一个命名空间的功能。
  2. 如果分别支持这两类导出、导入也会增加用户理解成本。导入一个文件用户可能不太确定是导入到当前命名空间,还是manifest指定的命名空间。
  3. 产品交互逻辑上希望传达:在指定命名空间操作的数据只作用在当前命名空间这个一致逻辑;本次想增加的功能和这点有冲突。
  4. 后续如果系统为用户增加命名空间数据权限,那么本次想增加的功能还可能突破这个限制,或者操作被限制中断。
  5. 目前r-nacos的配置导出、导入与nacos的逻辑基本一致,新增加的功能同时也破坏这个一致性。

综上所述:增加这个功能的优点不大,缺点比较多,以目前的方式引入这个功能可能不太合适。

moyu-x commented 3 months ago

这个简单说下我们的解决思路,可以做个参考,就是会有点限制,毕竟 nacos 支持的类型比较多,我这边可以贡献个 go 写的(rust 不太熟😂):

  1. 导出的格式使用properties,这样可以同时支持 Apollo及 nacos,也能用于自建的 spring cloud config
  2. 命名使用 namespaceId _groupid _dataid 的方式,这样就可以支持apllo 和 nacos 的解析,这两个的结构层次是一致的
  3. 使用全量替换的方式,这样可以避免出错
heqingpan commented 3 months ago

这个简单说下我们的解决思路,可以做个参考,就是会有点限制,毕竟 nacos 支持的类型比较多,我这边可以贡献个 go 写的(rust 不太熟😂):

  1. 导出的格式使用properties,这样可以同时支持 Apollo及 nacos,也能用于自建的 spring cloud config
  2. 命名使用 namespaceId _groupid _dataid 的方式,这样就可以支持apllo 和 nacos 的解析,这两个的结构层次是一致的
  3. 使用全量替换的方式,这样可以避免出错

这个规则也需要二次加工后才能于nacos兼容。如果需要二次加工的话,使用二进程格式也没有问题。

另外文件的规则也可能出现歧义、冲突,比如groupId或dataId中有'_'解析时可能会有问题。