聊聊 Nacos 配置隔离和分类的使用

标签: dev | 发表时间:2019-11-26 00:00 | 作者:
出处:http://itindex.net/relian




今天的主题还是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)
  


-

3

-

配置使用


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

 

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

 

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

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

 

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




相关 [nacos 隔离 分类] 推荐:

聊聊 Nacos 配置隔离和分类的使用

- - IT瘾-dev
最近在使用Nacos来作为配置中心和注册中心,在使用的过程难免会有些问题. 有的是框架问题,有的是使用方式的问题,不久前也分享了一篇 《最近使用Nacos的一些问题》,感兴趣的可以看看. 今天要聊的话题也是在使用过程中发现的,主要是前期赶进度太忙了,停下来之后才有时间去整理,去思考更优的方式. 环境隔离是最基本的一个需求,在日常开发过程中,常需要不同的环境,比如开发,测试,预发,线上环境.

扩展Ribbon支持Nacos集群配置

- - 周立的博客 - 关注Spring Cloud、Docker
在Nacos上,支持集群配置. 集群是对指定微服务的一种虚拟分类. 为了容灾,把指定微服务同时部署在两个机房(例如同城多活【其中1个机房崩溃另一个机房还能顶】、异地多活【防止自然灾害,例如地震什么的】),比如南京机房和北京机房. 调用时,可优先调用同机房的实例,如果同机房没有实例,再跨机房调用. 当然cluster还有很多其他作用,请各位看客自行脑补,本文将围绕上面描述的场景展开.

事务隔离和传播

- - 数据库 - ITeye博客
- Spring中事务的Propagation(传播性)的取值.        -- 加入当前已有事务;只有当前没有事务才起一个新的事务.        比如说,ServiceB.methodB的事务级别定义为PROPAGATION_REQUIRED, 那么由于ServiceA.methodA的时候,ServiceA.methodA已经起了事务,这时调用ServiceB.methodB,ServiceB.methodB看到自己已经运行在ServiceA.methodA的事务内部,就不再起新的事务.

隔离术之使用 Hystrix 实现隔离

- - IT瘾-dev
本篇摘自《亿级流量网站架构核心技术》第三章 隔离术 部分内容,全文. 商品详情页系统的Servlet3异步化实践. Hystrix是Netflix开源的一款针对分布式系统的延迟和容错库,目的是用来隔离分布式服务故障. 它提供线程和信号量隔离,以减少不同服务之间资源竞争带来的相互影响;提供优雅降级机制;提供熔断机制使得服务可以快速失败,而不是一直阻塞等待服务响应,并能从中快速恢复.

使用VitrualEnvWrapper隔离python项目的库依赖

- jeff - Jeff的妙想奇境
VirtualEnv用于在一台机器上创建多个独立的python运行环境,VirtualEnvWrapper为前者提供了一些便利的命令行上的封装. - 隔离项目之间的第三方包依赖,如A项目依赖django1.2.5,B项目依赖django1.3. - 为部署应用提供方便,把开发环境的虚拟环境打包到生产环境即可,不需要在服务器上再折腾一翻.

数据库隔离级别导致的问题

- - Java - 编程语言 - ITeye博客
java代码在开始事务后,先做了一个查询,再insert,此时会报: ERROR JDBCExceptionReporter:78 - Could not retrieve transation read-only status server. 问题解决过程: 查看mysql的事物隔离级别.                                            返回结果: REPEATABLE-READ.

MySQL数据库事务隔离级别(Transaction Isolation Level)

- - RSS - IT博客云
修改事务隔离级别的方法:. 1.全局修改,修改 mysql.ini配置文件,在最后加上. 1 #可选参数有: READ-UNCOMMITTED, READ-COMMITTED, REPEATABLE-READ, SERIALIZABLE. 这里全局默认是 REPEATABLE-READ,其实MySQL本来默认也是这个级别.

spring-cloud中zuul的两种隔离机制实验

- - ImportNew
ZuulException REJECTED_SEMAPHORE_EXECUTION 是一个最近在性能测试中经常遇到的异常. 查询资料发现是因为zuul默认每个路由直接用信号量做隔离,并且默认值是100,也就是当一个路由请求的信号量高于100那么就拒绝服务了,返回500. 既然默认值太小,那么就在gateway的配置提高各个路由的信号量再实验.

美研制硅波导可隔离光信号 利于研发光子芯片

- 帝 - cnBeta.COM
美国科学家在8月5日出版的《科学》杂志上撰文指出,他们研制出了一块新的硅基光学波导,能将硅芯片上的光信号隔离开,解决了建造光子芯片长期存在的问题,为下一代光子芯片的研制铺平了道路. 与电子芯片相比,光子芯片拥有超高速的运算速度、超大规模的信息存储容量、能量消耗小、散发热量低等优点,因此,用光子代替电子实现数据连接是不可阻挡的历史潮流,不过,现在的计算机技术主要还是依靠电子芯片.

理解事务——原子性、一致性、隔离性和持久性

- - CSDN博客架构设计推荐文章
事务是指对系统进行的一组操作,为了保证系统的完整性,事务需要具有ACID特性,具体如下:.      一个事务包含多个操作,这些操作要么全部执行,要么全都不执行. 实现事务的原子性,要支持回滚操作,在某个操作失败后,回滚到事务执行之前的状态.      回滚实际上是一个比较高层抽象的概念,大多数DB在实现事务时,是在事务操作的数据快照上进行的(比如,MVCC),并不修改实际的数据,如果有错并不会提交,所以很自然的支持回滚.