今天的主题还是Nacos

正所谓一入江湖身不由己

至今还在探索中

如今到底如何

↓↓

最近在使用Nacos来作为配置中心和注册中心，在使用的过程难免会有些问题。有的是框架问题，有的是使用方式的问题，不久前也分享了一篇《最近使用Nacos的一些问题》，感兴趣的可以看看。

今天要聊的话题也是在使用过程中发现的，主要是前期赶进度太忙了，停下来之后才有时间去整理，去思考更优的方式。

-

1

-

环境隔离

环境隔离是最基本的一个需求，在日常开发过程中，常需要不同的环境，比如开发，测试，预发，线上环境。

在Nacos中有命名空间的概念，通过空间来支持多环境隔离，也就是一个环境对应一个命名空间

我们可以创建如下图所示的多个空间来进行隔离：

如果需要物理隔离，就要部署多套Nacos环境，我们目前就是部署的多套，部署多套的主要原因就是目前还没有完善的权限控制，生产环境的配置直接暴露给所有人是很危险的事情，据说在下个版本中会增加权限相关的功能。

还有一种使用场景就是租户隔离，从多个租户(用户)的角度来看，每个租户(用户)可能会有自己的 namespace,每个租户(用户)的配置数据以及注册的服务数据都会归属到自己的 namespace 下，以此来实现多租户间的数据隔离。例如超级管理员分配了三个租户，分别为张三、李四和王五。分配好了之后，各租户用自己的账户名和密码登录后，创建自己的命名空间。如下图所示：

但此功能还在规划中，后面才会支持。目前我们在使用上也在往这个方面靠拢，不同环境目前是通过多套部署来进行隔离，那么namespace我们就得用在其他地方才能体现它的价值和意义。

可以根据内部产品线来划分namespace，每个namespace下再细分配置文件，这样存在的一个问题是如果我多个产品线之前有共用的配置信息，也就是共享配置，目前看下来，只能每边都存放一份。

namespace已经隔离了，如果要跨namespace进行配置的共享，不知道后面有没有计划支持这样的功能。

Nacos的namespace设计也就是为了区分多环境或者多租户，这样来看跨namespace就属于特殊需求了，所以我们在做配置规划的需要需要考虑进去，有共同配置需要共享的，得放入相同的namespace中。

-

2

-

配置分类

一般在最开始使用的时候，也不会考虑太多，直接为每个项目建一个对应的application配置，所有的配置都放在里面。配置量少还可以，配置量大的时候不建议这么做，我们需要有具体的分类才能让配置更加的一目了然。

除了这个问题，还有就是像一些需要共用的配置，没有独立出来，每个项目的application中都存在一份相同的，万一哪天需要修改了，你会发现改了一个地方还不行，很多地方都得改，苦啊。。。

下面说下我是怎么分类的，每个人都有自己的想法，并没有什么标准，仅供参考：

Group

Group是用来分组的，默认是DEFAULT_GROUP，我这边分了三个组，如下：

• MIDDLEWARE_GROUP

中间件配置，比如Redis, Mq等。

• APPLICATION_GROUP

应用配置，比如jackson，SpringBoot Actuator等。

• BIZ_GROUP

业务配置，跟业务相关，比如订单超时未支付的时间，全局的邮费等。

DataId

DataId是配置的ID，也就是唯一标识。

通常以服务名称来命名，示列：

• xxx-order-biz (BIZ_GROUP)

• xxx-order-application (APPLICATION_GROUP)

中间件的配置就以中间件名称来命名，示列：

• xxx-redis (MIDDLEWARE_GROUP)

• xxx-rocketmq (MIDDLEWARE_GROUP)

• xxx-elasticsearch (MIDDLEWARE_GROUP)

有了细致的分类后，我们需要哪个配置就引入哪个DataId即可，不用全部引入，修改也不用每个配置文件都去修改，使用如下：

@NacosPropertySource(dataId = NacosConstant.REDIS, groupId = NacosConstant.MIDDLEWARE_GROUP, autoRefreshed = true)@NacosPropertySource(dataId = NacosConstant.ORDER_BIZ, groupId = NacosConstant.BIZ_GROUP, autoRefreshed = true)@NacosPropertySource(dataId = NacosConstant.ORDER_APPLICATION, groupId = NacosConstant.APPLICATION_GROUP, autoRefreshed = true)

最常用的我们是通过@NacosValue注解来读取对应的配置内容，比较尴尬的是经常忘记将@NacosValue中的autoRefreshed设置为true，然后就会发现配置修改了没实时生效，得重启才行。

我建议还是不要到处使用@NacosValue注解来读取配置，可以将配置统一管理起来，比如使用@NacosConfigurationProperties就很方便。

@Data@Configuration@NacosConfigurationProperties(dataId = NacosConstant.ORDER_BIZ, groupId = NacosConstant.BIZ_GROUP, autoRefreshed = true)public class OrderBizConfig {    private BigDecimal postage;}

像业务配置也有多种类型，每种类型就可以使用一个@NacosConfigurationProperties来管理，计算不用@NacosConfigurationProperties也可以创建一个单独的配置类，在这个类中使用@NacosValue，使用方就直接注入这个配置类，万一哪天配置的key要修改或者要去掉这个配置也非常方便。

@Data@Configurationpublic class OrderBizConfig {    @NacosValue(value = "${postage}", autoRefreshed = true)    private BigDecimal postage;}