SpringCloud核心组件(四)
SpringCloud核心组件(四)
JieNacos
Nacos 配置中心
在 Spring Boot 项目中,默认会提供一个 application.properties 或者 application.yml 文件,
可以把一些全局性
的配置或者需要动态维护
的配置写入改文件,比如数据库连接,功能开关,限流阈值,服务地址等。
为了解决不同环境下服务连接配置等信息的差异,Spring Boot 还提供了基于 spring.profiles.active={profile}的机制来实现不同的环境的切换。
1.起源
随着单体架构向微服务架构的演进,各个应用自己独立维护本地配置文件的方式开始显露出它的不足之处。
主要有下面几点:
配置的动态更新:在实际应用会有动态更新位置的需求,比如修改服务连接地址、限流配置等。在传统模式下,需要手动修改配置文件并且重启应用才能生效,这种方式效率太低,重启也会导致服务暂时不可用。
配置集中式管理:在微服务架构中某些核心服务为了保证高性能会部署上百个节点,如果在每个节点中都维护一个配置文件,一旦配置文件中的某个属性需要修改,可想而知,工作量是巨大的。
不同部署环境下配置的管理:前面提到通过 profile 机制来管理不同环境下的配置,这种方式对于日常维护来说也比较繁琐。
统一配置管理,就是弥补上述不足的方法。
简单说,是把各个应用系统中的某些配置放在一个第三方中间件上进行统一维护。
然后,对于统一配置中心上的数据的变更需要推送到相应的服务节点实现动态跟新,所以微服务架构中,配置中心也是一个核心组件。
2.基本概念
Profile
Java 项目一般都会有多个 Profile 配置,用于区分开发环境,测试环境,准生产环境,生成环境等,
每个环境对应一个 properties 文件(或是 yml/yaml 文件),然后通过设置 spring.profiles.active 的值来决定使用哪个配置文件。
1 | spring: |
Nacos Config的作用
就把这些文件的内容都移到一个统一的配置中心,即方便维护又支持实时修改后动态刷新应用。
Data ID
当使用 Nacos Config 后,Profile 的配置就存储到 Data ID 下,即一个 Profile 对应一个 Data ID
- Data ID 的拼接格式:
${prefix}-${spring.profiles.active}.${file-extension}
- prefix 默认为
spring.application.name
的值,也可以通过配置项spring.cloud.nacos.config.prefix
来配置 spring.profiles.active
取spring.profiles.active
的值,即为当前环境对应的profile
,当spring.profiles.active
为空时,对应的连接符 - 也将不存在,dataId 的拼接格式变成${prefix}.${file-extension}
file-extension
为配置内容的数据格式,可以通过配置项spring.cloud.nacos.config.file-extension
来配置。目前只支持properties
和yaml
类型。
Group
当配置项太多或者有重名时,可以通过分组来方便管理 , 这就是 Group
Group 默认为 DEFAULT_GROUP
,
可以通过 spring.cloud.nacos.config.group 来配置
3.基础配置
nacos 可以作为配置中心使用,在 payment 工程中如下步骤,启动 nacos 配置中心
a. bootstrap.yml
注意:Sprnig Boot 2.4.X 版本后需要手动添加 spring-cloud-starter-bootstrap 组件后,才能加载 bootstrap.yml 配置文件
1 | <!--nacos--> |
bootstrap.yml:
1 | spring: |
注意:spring.cloud.nacos.config 配置必须放到 bootstrap.yml 配置文件中,保证在优先读取配置文件再启动,否则配置无效
b. application.yml
1 | server: |
c. nacos 中的配置 DataID
1 | spring: |
d.测试读取配置中心配置内容
PaymentController
1 | package com.nianxi.controller; |
访问地址http://localhost:9001/payment/config/info
当修改配置值,会结果已经改变,Nacos 自带自动刷新功能。
4.配置隔离
通常,企业研发的流程是这样的:先在开发测试环境开发和测试功能,然后灰度,最后发布到生产环境。
并且,为了生产环境的稳定,需要将测试环境和生产环境进行隔离,Nacos 可以通过三种方式进行配置隔离:
- Nacos 的服务器
- namespace 命名空间
- group 分组,
在 bootstrap.yml 文件中可以通过配置 Nacos 的 server-addr、namespace 和 group 来区分不同的配置信息。
- Nacos 的服务器 spring.cloud.nacos.config.server-addr
- Nacos 的命名空间 spring.cloud.nacos.config.namespace,注意,这里使用命名空间的 ID 不是名称
- Nacos 的分组 spring.cloud.nacos.config.group
Nacos 配置隔离具体步骤如下:
a.命名空间
创建 dev,test,prod
b.DataID
在不同命名空间下创建如下 DataID(克隆即可)
注意稍微更改各自配置信息以作区别
c.bootstrap.yml
1 | spring: |
注意:如果不配置
namespace
默认为public
,不配置group
默认为DEFAULT_GROUP
此时读取的配置为 namespace=dev,group=MY_GROUP
的配置页面显示 config info dev my group
d.service 隔离
同样注册 service 时可以指定 namespace 隔离注册到哪一个命名空间。application.yml 如下:
1 | server: |
5.配置拆分
a.配置拆分策略
项目中会有很多的微服务,必然会存在很多具体配置,和重复配置,可以采用如下方案管理配置
根据上面分析在 nacos 中配置
配置在 public 中
b.DataID 配置
payment-service-dev.yaml
common.yaml
c.配置文件 bootstrap.yml
1 | spring: |
- 注:
extension-configs
配置属性和shared-configs
配置属性功能一致,都是读取配置文件,这里我们把重复配置
放到 common.yaml 中,这样在不同的工程中就可以重复使用[n]的值越大,优先级越高
。 - 注:
spring.application.name
和spring.profiles.active
配置必须
放到bootstrap.yml
中,否则影响配置自动刷新功能。
按照上面方案,整合拆分订单微服务的配置文件
order微服务bootstrap.yml
1 | spring: |
注意:这里两个工程使用重用的配置文件common.yaml