Nacos配置管理最佳实践
Nacos一个最常用的功能就是配置中心,在具体使用时往往是多个团队,甚至整个公司的研发团队都使用同一个Nacos服务。那么使用时如何保证配置在各个团队之间的隔离,又能保证配置管理的便捷性?下面就来介绍一个我使用下来比较好的实践方式。
namespace的划分
namespace的划分需要根据具体的开发团队规模来。
对于一些比较小的公司,开发人员比较少,可能就分成几个小团队,每个团队各自完成自己的开发任务。
对于这种情况,namespace的划分比较简单,就是给每个开发团队各自分配自己的namespace,团队之间的配置互相隔离。
比如说,现在A公司有4个开发团队,分别叫做T1、T2、T3和T4。
然后需要将Nacos配置成需要认证登录。
nacos.core.auth.enabled=true
nacos.core.auth.caching.enabled=true
给每个开发团队创建一个登录用户
给每个用户设置权限,只能访问自己团队的命名空间(下面的角色ROLE_T1,只能访问T1这个namespace)
经过上面的一系列配置之后,每个团队就只能访问自己的namespace了,起到了配置隔离的目的。
上面针对的是比较小的开发团队。那如果开发人员很多呢?比如说像一些大的公司会分成很多BU,每个BU下面会有自己的许多开发团队。针对这种情况,可以对每个BU进一步进行namespace划分,比如说将BU1下面的开发划分成T1、T2、T3,然后对每个团队的命名空间管理和上面的管理方案一致。
对于一些大的事业部,上面的这种划分方式其实是很“粗犷”的方式,其实更建议每个事业部维护自己的的Nacos服务,这样可以进行更加精细的划分。
groupId、dataId的分配
上面讲了namespace的划分。从上面的划分规则中,我们可以看出来其实我们是按照团队的维度来划分namespace的(官网上面介绍namespace的主要作用是用来划分租户的,但是这个租户是什么概念并没有具体说明,那就可以是团队、可以是BU、甚至是个人,我们这里以团队的维度来划分)。
那就引出一个问题了:当我们新增配置文件时,需要指定groupId和dataId。其中groupId从名字上看好像就是团队ID。那是不是说,在同一个namespace下的配置文件的groupid都设置成一个?我觉得这样不是一个好的实践方式。
我们团队是这样规划的。groupid取项目的名字,dataId取模块和环境的组合名字。
举个栗子:现在BU1-T1团队在同时开发两个项目:Project1和Project2,每个项目都是分多个模块的微服务项目,Project1下面有2个模块m1和m2,Project2下面分三个模块m1、m2和m3。
那么可以进行如下的配置:
好了,上面就是我在Nacos配置管理上面的实践。
相关文章
- Nacos 2.1.1 正式发布,真心强!
- Nacos动态刷新配置
- Nacos客户端注册报错
- Nacos安装指南Windows和Linux
- Alibaba Nacos 权限认证绕过漏洞
- Nacos简介
- Nacos作为配置中心
- SpringCloudAlibaba入门系列(3) - 服务治理组件Nacos
- Sentinel规则持久化进Nacos
- nacos数据持久化
- Nacos组件(服务注册中心测试)
- Spring Cloud 整合 nacos 实现动态配置中心
- Nacos 版本不一致报错: Request nacos server failed
- 漏洞复现-Nacos身份认证绕过
- Alibab Nacos未授权登录后台通告
- Nacos 惊爆安全漏洞,可绕过身份验证(附修复建议)
- Gateway+Nacos根据服务名称实现动态路由报错:type=Service Unavailable, status=503
- Nacos与Oracle的对比哪种数据服务更可靠(nacos oracle)