源码地址:https://gitee.com/fighter3/eshop-project.git
持续更新中……
在我们前面介绍Nacos的时候,说到,Nacos除了可以作为注册中心,还可以作为配置中心,而在SpringCloud Netfilx的体系下,这个工作是由Spring Cloud Config完成的。
至于为什么需要配置中心?大家想一下,在微服务开发体系下,整个系统可能被拆分成几十、上百个服务,在生产的时候,每个服务可能部署几十上百个节点,而且通常是又多个环境,如开发、测试、预发布、成产等等,如果没有一个集中式的配置中心,一个个去管理,那是一个多么😥的事情。
好了,接下来我们开始愉快地学习Nacos作为分布式配置中心吧!
1、Nacos配置基本概念
在正式开始实战之前,我们先了解一下Nacos配置的一些基本概念。
上图我们可以看到Nacos作为配置中心的几个主要概念:
- 命名空间
区分环境,比如:dev、test、prod 等等。
用于进行租户粒度的配置隔离。不同的命名空间下,可以存在相同的 Group 或 Data ID 的配置。Namespace 的常用场景之一是不同环境的配置的区分隔离,例如开发测试环境和生产环境的资源(如配置、服务)隔离等。
- 配置分组
多个配置文件放在一起,形成组,一般用于区分项目。例如,某学校多应用之间的区分,教师应用 TEACHER_GROUP,学生应用 STUDENT_GROUP。
Nacos 中的一组配置集,是组织配置的维度之一。通过一个有意义的字符串(如 Buy 或 Trade )对配置集进行分组,从而区分 Data ID 相同的配置集。当您在 Nacos 上创建一个配置时,如果未填写配置分组的名称,则配置分组的名称默认采用 DEFAULT_GROUP 。配置分组的常见场景:不同的应用或组件使用了相同的配置类型,如 database_url 配置和 MQ_topic 配置。
- 配置集
多个键值对,一般指一个配置文件。
一组相关或者不相关的配置项的集合称为配置集(多个键值对/一个配置文件)。在系统中,一个配置文件通常就是一个配置集,包含了系统各个方面的配置。例如,一个配置集可能包含了数据源、线程池、日志级别等配置项。
- 配置集ID
给这个配置文件起一个全局唯一的 ID。
Nacos 中的某个配置集的 ID。配置集 ID 是组织划分配置的维度之一。Data ID 通常用于组织划分系统的配置集。一个系统或者应用可以包含多个配置集,每个配置集都可以被一个有意义的名称标识。Data ID 通常采用类 Java 包(如 com.taobao.tc.refund.log.level)的命名规则保证全局唯一性。此命名规则非强制。
- 配置项
一个键值对 <Key = Value>
一个具体的可配置的参数与其值域(一个键值对),通常以 param-key=param-value 的形式存在。例如我们常配置系统的日志输出级别(logLevel=INFO|WARN|ERROR) 就是一个配置项。
给大家看一个Nacos的配置示例,这些概念相信你就都明白。
2、引入Nacos配置中心
我们以eshop-user为例演示我们的配置中心。
2.1、引入nacos-config依赖
<!-- spring cloud alibaba nacos config 依赖 --> <dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId> </dependency>
2.2、配置文件
和SpringCloud Config类似,我们必需要在 bootstrap.yml
配置文件中进行配置,在application.yml
中无效,bootstrap.yml
优先级高于application.yml
。
spring: application: name: user-service # 应用名称 profiles: active: dev # 当前环境对应的 profile cloud: nacos: config: enabled: true # 如果不想使用 Nacos 进行配置管理,设置为 false 即可 server-addr: 127.0.0.1:8848 # Nacos Server 地址 group: DEFAULT_GROUP # 组,默认为 DEFAULT_GROUP file-extension: yaml # 配置内容的数据格式,默认为 properties
说明:之所以需要配置
spring.application.name
,是因为它是构成 Nacos 配置管理dataId
字段的一部分。
在 Nacos Spring Cloud 中,dataId
的完整格式如下:
${prefix}-${spring.profile.active}.${file-extension}
prefix
默认为spring.application.name
的值,也可以通过配置项spring.cloud.nacos.config.prefix
来配置。spring.profile.active
即为当前环境对应的 profile。注意:当spring.profile.active
为空时,对应的连接符-
也将不存在,dataId 的拼接格式将变成${prefix}.${file-extension}
file-exetension
为配置内容的数据格式,可以通过配置项spring.cloud.nacos.config.file-extension
来配置。目前只支持properties
和yaml
类型,默认为properties
。
2.3、Nacos Server创建配置
我们在Nacos Server的配置列表中新建一个配置。
Data Id
为 user-service.yaml
,组使用默认组,并添加 yaml
格式的配置信息。
project: name: e-shop-userservice author: fighter3
2.4、控制层
使用 Spring 的 @Value
注解来获取配置信息,${}
中对应 Nacos 配置中心配置内容的 key,:
后跟默认值。
并且通过 Spring Cloud 原生注解 @RefreshScope
实现配置自动更新。
/** * @Author: 三分恶 * @Date: 2021/5/30 * @Description: Nacos配置项获取 **/ @RefreshScope @RestController @RequestMapping("/shop-user") @Api(value = "配置信息接口", tags = "配置信息接口") public class NacosConfigController { @Value("${project.name:}") private String projectName; @Value("${project.author:}") private String projectAuthor; @GetMapping("/config") @ApiOperation(value = "获取Nacos配置项") public Map<String, Object> getConfig() { Map<String, Object> configMap = new HashMap(); configMap.put("projectName", projectName); configMap.put("projectAuthor", projectAuthor); return configMap; } }
2.5、测试
启动user-service
服务。
访问knife4j接口地址:http://localhost:8080/doc.html ,调用获取Nacos配置项接口:
接下来,我们修改一下配置项,并发布:
可以看到控制台打印输出:
再次访问获取配置接口:
OK,到这我们已经成功地读取了Nacos配置中心的配置,接下来,我们尝试将服务的配置,例如数据源来进行统一的集中配置。
3、集中配置
好,我们开始进行Nacos集中配置的实战:
3.1、新建命名空间
我们之前用的是默认的命名空间,接下来我们创建一个新的命名空间,用于我们开发环境的配置。我们给它命名为dev_space
:
这里使用了命名空间来隔离配置,如果我们想要一个测试环境的配置,如法炮制,建一个新的空间就行了。
3.2、创建数据源配置
接下来我们在dev_space
下创建一个新的配置user-service-dev.yaml
project: name: e-shop-userservice author: fighter3 # 数据源配置 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/shop_user?characterEncoding=utf-8&allowMultiQueries=true&serverTimezone=GMT%2B8 username: root password: root
3.3、修改本地配置
我们在bootstrap.yml中指定命名空间,完整bootstrap.yml如下:
spring: application: name: user-service # 应用名称 profiles: active: dev # 当前环境对应的 profile cloud: nacos: config: enabled: true # 如果不想使用 Nacos 进行配置管理,设置为 false 即可 server-addr: 127.0.0.1:8848 # Nacos Server 地址 group: DEFAULT_GROUP # 组,默认为 DEFAULT_GROUP file-extension: yaml # 配置内容的数据格式,默认为 properties namespace: dev_space # 指定命名空间,默认为public
修改application.yml,注释掉数据源相关配置:
3.4、测试
启动用户服务,服务正常启动以后,我们分别调试获取用户信息接口和获取配置接口。
OK,获取到了预期的结果。
好了,Nacos作为分布式配置中心的实战到此结束了,了解更多可以直接查看官方文档!
系列文章持续更新中!
“简单的事情重复做,重复的事情认真做,认真的事情有创造性地做!”——
我是三分恶,可以叫我老三/三分/三哥/三子,一个能文能武的全栈开发,咱们下期见!