2023.0.1.3+版本接入Nacos配置中心参数兼容性问题说明
-
2023.0.1.3+版本升级导致的不兼容问题 关于不兼容变更,我们内部进行了沟通确定,但是在版本正式对外发布过程中对于不兼容的变更说明和公告发布存在沟通问题,导致参数变更说明延迟发布 ,对于各位社区同学在升级过程中遇到的不兼容问题,我们深表歉意。
-
2023.0.1.3+版本接入NacosConfig的标准用法
导入单个配置:
导入多个配置:
对于之前通过application.name拼接模式以及share-configs,extension-configs等方式导入的配置,需要统一修改spring.config.import模式进行配置导入。
-
2023.0.1.3版本中做的改动 在2023.0.1.3版本中,为了支持在SpringBoot中接入Nacos配置中心以及基于原有的nacos config模块之上支持@NacosConfig,@NacosConfigListener注解,我们将spring-cloud-starter-alibaba-nacos-config模块进行了拆分,拆分为spring-alibaba-nacos-config(仅依赖SpringBoot,支持在非SpringCloud应用中独立使用)和新的spring-cloud-starter-alibaba-nacos-config(仅保留依赖SpringCloud的组件),在模块拆分的过程中,我们发现随着代码不断的变更,配置的加载逻辑存在多个分支,包括最初版本中通过拼接spring.application.name以及fileExtension等参数,通过share-configs,extension-configs以及spring.config.import。多个属性源加载时机不一致且代码逻辑分叉,不利于配置模块的扩展,出于代码的可维护性考虑,我们对配置加载逻辑进行了删减,仅保留了spring在Spring Boot 2.4.0 (2020年11月12日)推出的spring.config.import标准配置导入方式,在该版本中Spring同时建议废弃bootstrap模式启动,统一迁移到application.properties。
-
关于spring-alibaba-nacos-config组件未来的计划 正如上文所说,对旧代码的删除是为了降低维护成本以及未来更快更好的发展,在最新2023.0.3.3版本中我们支持数据库连接池druid的运行期无损轮转的功能,spring-alibaba-nacos-config模块未来将承载更多职责,面向二方中间件组件,对SpringBoot(包括Spring AI)以及SpringCloud应用提供统一的配置托管以及运行时无损轮转功能,面向普通的业务组件,通过@NacosConfig,@NacosConfigListener注解提供灵活易用的配置注入和变更回调能力。
!!!非常希望能够支持像之前一样的配置方式!!! 当前的config.import语法的手工配置项太多,且复杂。 我们当前项目通过统一的配置文件,大幅度简化配置,打包到镜像之后,很容易通过环境变量适配多个环境。 比如如下的bootstrap.yml文件。
project:
name: @project.name@
version: @project.version@
spring:
application:
name: ${project.name}
cloud:
nacos:
server-addr: ${NACOS_SERVER}
username: ${NACOS_USERNAME}
password: ${NACOS_PASSWORD}
config:
namespace: ${NACOS_NAMESPACE}
file-extension: yaml
discovery:
namespace: ${spring.cloud.nacos.config.namespace}
service: ${spring.application.name}
ip: ${APP_HOST:}
1、application.yml 的加载顺序不够靠前,默认的一些配置无法在spring boot启动的时候加载到,比如 logger.level 2、使用 spring cloud时,项目可以支持 bootstrap.yml,那么 我能否使用之前的方式 在 bootstrap.yml 中配置?还是说必须使用 spring.config.import ?
!!!非常希望能够支持像之前一样的配置方式!!! 当前的config.import语法的手工配置项太多,且复杂。 我们当前项目通过统一的配置文件,大幅度简化配置,打包到镜像之后,很容易通过环境变量适配多个环境。 比如如下的bootstrap.yml文件。
project: name: @project.name@ version: @project.version@
spring: application: name: ${project.name} cloud: nacos: server-addr: ${NACOS_SERVER} username: ${NACOS_USERNAME} password: ${NACOS_PASSWORD} config: namespace: ${NACOS_NAMESPACE} file-extension: yaml discovery: namespace: ${spring.cloud.nacos.config.namespace} service: ${spring.application.name} ip: ${APP_HOST:}
spring.config.import中的dataId,group也可以通过${}占位符动态指定,shared-configs和ext-configs也是需要指定dataId和group,并没有区别
!!!非常希望能够支持像之前一样的配置方式!!! 当前的config.import语法的手工配置项太多,且复杂。 我们当前项目通过统一的配置文件,大幅度简化配置,打包到镜像之后,很容易通过环境变量适配多个环境。 比如如下的bootstrap.yml文件。
project: name: @project.name@ version: @project.version@
spring: application: name: ${project.name} cloud: nacos: server-addr: ${NACOS_SERVER} username: ${NACOS_USERNAME} password: ${NACOS_PASSWORD} config: namespace: ${NACOS_NAMESPACE} file-extension: yaml discovery: namespace: ${spring.cloud.nacos.config.namespace} service: ${spring.application.name} ip: ${APP_HOST:}
你们这也没啥特殊的 用新版一样 没区别
其实 config 的配置方式有了变化统一更新一下文档说明一下即可。这里还有另外一个问题,就是:是否不再支持 Bootstrap 方式。
我看代码中 NacosConfigBootstrapConfiguration 和 NacosConfigSpringCloudBootstrapConfiguration 两个配置类还是在的,但是没有任何地方注入。这是否说明就彻底放弃了对 Bootstrap 方式的支持。
另外,NacosConfigBootstrapConfiguration 和 NacosConfigSpringCloudBootstrapConfiguration 两个配置类的 Condition 条件是错误的。
其实 config 的配置方式有了变化统一更新一下文档说明一下即可。这里还有另外一个问题,就是:是否不再支持 Bootstrap 方式。
我看代码中 NacosConfigBootstrapConfiguration 和 NacosConfigSpringCloudBootstrapConfiguration 两个配置类还是在的,但是没有任何地方注入。这是否说明就彻底放弃了对 Bootstrap 方式的支持。
另外,NacosConfigBootstrapConfiguration 和 NacosConfigSpringCloudBootstrapConfiguration 两个配置类的 Condition 条件是错误的。
Spring官方是不再推荐使用bootstrap的方式的,因此Spring Cloud Alibaba也不再推荐使用
其实 config 的配置方式有了变化统一更新一下文档说明一下即可。这里还有另外一个问题,就是:是否不再支持 Bootstrap 方式。 我看代码中 NacosConfigBootstrapConfiguration 和 NacosConfigSpringCloudBootstrapConfiguration 两个配置类还是在的,但是没有任何地方注入。这是否说明就彻底放弃了对 Bootstrap 方式的支持。
另外,NacosConfigBootstrapConfiguration 和 NacosConfigSpringCloudBootstrapConfiguration 两个配置类的 Condition 条件是错误的。
Spring官方是不再推荐使用bootstrap的方式的,因此Spring Cloud Alibaba也不再推荐使用
嗯,感谢回复。这两天仔细看了一下,确实该放弃 Bootstrap 模式了。https://github.com/alibaba/spring-cloud-alibaba/issues/3995#issuecomment-2999557096
SCA 2023.0.1.3 以及之后的版本变化,一方面是为了提取共用模块;另一方面是不打算再兼容 Bootstrap 模式。
因为,确实是 Boostrap 模式是兼容的模式,是 Spring 本身也已经不再推荐使用。
所以,现在最好的办法就是:
- 把现在所有的 Nacos 配置,全部改成
spring.config.import的方式 - 把服务中的 Bootstrap.yml 全部改成 application.yml
这样的话spring-cloud-starter-boostrap 也不需要依赖了。这样操作之后,现在的 SCA 2023.0.3.3 就直接可以用,不会有任何问题。
这两天我也仔细看了看。我提交的 PR #4069 也仅是兼容老用户 Bootstrap 模式的补救措施。与 SCA 新版本的用法不符,也不符合 Spring 的规范。
因为 Bootstrap 模式还是需要依赖于
spring.factories配置文件,但这个文件已经不是 Spring Boot 3.x 标准用法了,由此可见 不推荐 Bootstrap 模式是对的,早晚要被淘汰。特别是今年的年底要发布 Spring Boot 4.X 了。
@shiyiyue1102
拆分后 仅使用springboot依赖时,namespace好像不支持了?
拆分后 仅使用springboot依赖时,namespace好像不支持了?
是支持的,这个metadata.json会影响参数在idea中的提示,只要配置了会生效的,在后续版本中会处理下这个metadata.json的问题
使用import后 配置加密怎么搞了,nacos地址等信息全部使用密文,然后重写EnvironmentPostProcessor的方式实现配置加密,现在使用import之后就不好用了,这个怎么搞
EnvironmentPostProcessor
你指的是在application.properties里设置的spring.cloud.nacos.config.server-addr参数吧,这部分理论上是不受影响的,可以debug看下EnvironmentPostProcessor有没有被加载
EnvironmentPostProcessor
你指的是在application.properties里设置的spring.cloud.nacos.config.server-addr参数吧,这部分理论上是不受影响的,可以debug看下EnvironmentPostProcessor有没有被加载
EnvironmentPostProcessor正常加载没有问题,密文也确实解析成了明文,我特意将其他的配置都设置成明文,只将namespace设置为密文,使用import,查看日志打印的确实是nacos加载了密文的namespace
EnvironmentPostProcessor
你指的是在application.properties里设置的spring.cloud.nacos.config.server-addr参数吧,这部分理论上是不受影响的,可以debug看下EnvironmentPostProcessor有没有被加载
EnvironmentPostProcessor正常加载没有问题,密文也确实解析成了明文,我特意将其他的配置都设置成明文,只将namespace设置为密文,使用import,查看日志打印的确实是nacos加载了密文的namespace
这里可能存在初始化顺序的问题, spring cloud加载nacos配置是在启动的早起,可能是在你的自定义EnvironmentPostProcessor之前,可以debug看下
This issue has been open 30 days with no activity. This will be closed in 7 days.
This issue has been automatically marked as stale because it hasn't had any recent activity.If you think this should still be open, or the problem still persists, just pop a reply in the comments and one of the maintainers will (try!) to follow up. Thank you for your interest and contribution to the Sping Cloud Alibaba Community.
不用bootstrap,不同环境下的nacos地址、namespace怎么配置?我试了半天,最终还是把bootstrap引入进来了。。。。 问ai后才知道,spring.config.import优先解析,解析到需要使用nacos时,就会读取application.yaml中nacos的连接地址配置,进而连接nacos并获取配置信息。最后才根据spring.profiles.active加载别的配置文件,所以即使设置spring.profiles.active=dev,并在application-del.yaml中配置了开发环境的nacos地址,也是读取不到的。
这种情况在类上留一个@ConfigurationProperties(prefix = "spring.cloud.nacos.config") 至少即保证了向前兼容性、又不影响下面那几个配置用动态前缀获取配置进行覆盖。
按照惯用的兼容性维护标准,要删除的特性至少要先标记过时,最后大版本升级再移除相关支持。
麻烦当BUG处理一下吧。
nacos覆盖不了profiles.include的配置,用spring-cloud-starter-boostrap组件,配置文件使用bootstrap.yml可以生效。
application.yml
spring:
application:
name: xx
profiles:
active: ${PROFILES:dev}
include: base,rpc
cloud:
nacos:
username: ${NACOS_USERNAME}
password: ${NACOS_PASSWORD}
server-addr: ${NACOS_ADDR}
config:
file-extension: yaml
namespace: ${spring.profiles.active}
config:
import:
- nacos:common.${spring.cloud.nacos.config.file-extension}?refreshEnabled=true
- nacos:${spring.application.name}.${spring.cloud.nacos.config.file-extension}?refreshEnabled=true
base,rpc是打包到jar中的,项目引入jar在通过include来引入配置
@huliua 把 application-dev.yml 文件放到file:./下,可以比 nacos 配置加载的早,亲测有效。
方式1、同一文件不同块不支持,未成功解析${custom.nacos.config.group}变量
---
spring:
config:
activate:
on-profile: my_test
custom.nacos.config:
group: test
---
spring:
profiles:
active: my_test
config:
import:
- optional:nacos:test.yml?group=${custom.nacos.config.group}&refreshEnabled=true
方式2、不同文件不支持,未成功解析${custom.nacos.config.group}变量
#######
application-my_test.yml
custom.nacos.config:
group: test
#######
application.yml
spring:
profiles:
active: my_test
config:
import:
# 如下的手工方式引入也不行
#- optional:classpath:application-dev_localhost.yml
#- optional:classpath:application-${spring.profiles.active}.yml
- optional:nacos:test.yml?group=${custom.nacos.config.group}&refreshEnabled=true