|
该版本仍在开发中，尚未被视为稳定。最新稳定版本请使用Spring Cloud Commons 5.0.0！ |
Spring Cloud Context：应用上下文服务
Spring Boot 对如何用 Spring 构建应用有着独特的观点。 例如，它有常规的配置文件位置，并有用于常见管理和监控任务的端点。 Spring Cloud 在此基础上构建，增加了一些系统中许多组件会使用或偶尔需要的功能。
Bootstrap 应用上下文
Spring Cloud 应用通过创建“引导”上下文来运行，该上下文是主应用程序的父上下文。
该上下文负责从外部来源加载配置属性，并解密本地外部配置文件中的属性。
这两个上下文共享一个环境，是任何Spring应用外部属性的来源。
默认情况下，bootstrap 属性（不是bootstrap.properties但在引导阶段加载的属性则优先级较高，因此无法被局部配置覆盖。
引导上下文使用与主应用上下文不同的外部配置定位约定。
而不是application.yml（或。性能），你可以使用bootstrap.yml保持了引导和主上下文的外部配置分开。
以下列表展示了一个示例：
spring:
application:
name: foo
cloud:
config:
uri: ${SPRING_CONFIG_URI:http://localhost:8888}
如果你的应用需要服务器提供任何特定应用配置，建议设置spring.application.name（在bootstrap.yml或application.yml).
对于该地产spring.application.name要用作应用的上下文ID，必须将其设置为启动。[属性 | YML].
如果你想获取特定的配置文件配置，你还应该设置春季.档案.活跃在启动。[属性 | YML].
你可以通过设置完全禁用引导进程spring.cloud.bootstrap.enabled=false（例如，在系统属性中）。
应用上下文层级
如果你从 构建应用上下文SpringApplication或SpringApplicationBuilder，Bootstrap 上下文作为该上下文的父节点添加。
Spring 的一个特性是子上下文继承父上下文的属性源和配置文件，因此“主”应用上下文包含额外的属性源，而构建相同的上下文时不使用 Spring Cloud 配置。
其他财产来源包括：
-
“自助”：如果有的话
PropertySourceLocators在引导框架上下文中发现，如果它们具有非空属性，则可选CompositePropertySource优先级很高。 比如 Spring Cloud 配置服务器的属性。 请参阅“自定义Bootstrap属性源”，了解如何自定义该属性源的内容。
春云2022.0.3之前PropertySourceLocators（包括 Spring Cloud 配置的那些）在
主要应用上下文，而非引导模式。你可以强行PropertySourceLocators将在
按设置设置的引导上下文spring.cloud.config.initialize-on-context-refresh=true在启动。[属性 | yaml]. |
-
“applicationConfig： [classpath:bootstrap.yml]”（以及如果Spring配置文件活跃的相关文件）：如果你有
bootstrap.yml（或。性能这些属性用于配置引导上下文。 然后当子上下文的父上下文被设置时，它们会被添加到子上下文中。 它们的优先级低于application.yml（或。性能）以及作为创建 Spring Boot 应用程序过程中正常过程添加到子节点的其他属性源。 请参阅“更改 Bootstrap 属性的位置”，了解如何自定义这些属性源的内容。
由于属性源的排序规则，“自助”条目优先。
但请注意，这些数据不包含来自bootstrap.yml，其优先级非常低，但可用于设置默认值。
你可以通过设置任意的父上下文来扩展上下文层级应用上下文你可以创建——例如，通过使用它自己的接口或SpringApplicationBuilder便利方法 （parent（）,child（）和兄弟姐妹（）).
自助式上下文是你自己创建的最长祖先的父系。
层级结构中的每个语境都有自己的“自助式”（可能是空的）属性源，以避免无意中从父母传递到后代的价值。
如果存在配置服务器，层级结构中的每个上下文原则上也可以有不同的spring.application.name因此，也就有一个不同的偏远地产源。
正常的 Spring 应用上下文行为规则适用于属性解析：子上下文中的属性覆盖了
父级，按名称，也按属性源名称。
（如果子节点的属性源与父节点同名，则该子节点的值不会包含在子节点中。）
注意SpringApplicationBuilder让你共享一个环境在整个等级体系中，但这并不是默认的。
因此，兄弟情境（尤其是）不必拥有相同的配置文件或属性来源，尽管它们可能与父节点共享共同价值。
改变引导属性的位置
这bootstrap.yml（或。性能）位置可以通过设置来指定spring.cloud.bootstrap.name（默认：启动),spring.cloud.bootstrap.location（默认：空） 或spring.cloud.bootstrap.additional-location（默认：空）——例如，在系统属性中。
这些属性的表现类似于spring.config.*同名的变体。
跟spring.cloud.bootstrap.location默认位置会被替换，只使用指定的位置。
要把位置添加到默认位置列表，spring.cloud.bootstrap.additional-location可以使用。
事实上，它们被用来建立引导程序应用上下文通过将其属性设置为环境.
如果存在活跃的配置文件（来自）春季.档案.活跃或者通过环境在你正在构建的上下文中，API中的属性也会被加载，就像普通的Spring Boot应用一样——例如，来自bootstrap-development.properties对于发展轮廓。
覆盖远程属性的值
引导上下文添加到应用中的属性源通常是“远程”的（例如，来自 Spring Cloud 配置服务器）。
默认情况下，它们无法在本地被覆盖。
如果你想让应用程序用自己的系统属性或配置文件覆盖远程属性，远程属性源必须通过设置来赋予它权限spring.cloud.config.allowOverride=true（本地设置此功能无法实现）。
一旦该标志设置好，两个更细粒度的设置控制远程属性相对于系统属性的位置以及应用程序的本地配置：
-
spring.cloud.config.overrideNone=true：从任何本地属性源覆盖。 -
spring.cloud.config.overrideSystemProperties=false： 只有系统属性、命令行参数和环境变量（本地配置文件除外）应覆盖远程设置。
自定义Bootstrap配置
引导上下文可以通过添加 的条目来设置任意功能/元-INF/spring.factories在一个名为org.springframework.cloud.bootstrap.BootstrapConfiguration.
这里有一个逗号分隔的春季列表@Configuration用于创建上下文的类。
任何你希望能在主应用上下文中获得的自动接线豆子都可以在这里创建。
有一份特别合同@Beans类型应用上下文初始化器.
如果你想控制启动序列，可以用@Order注释（默认顺序为最后).
添加自定义时BootstrapConfiguration注意你添加的类别不是@ComponentScanned错误地进入了你的“主”应用上下文，可能不需要它们。
为启动配置类使用单独的包名，并确保该名称没有被你的@ComponentScan或@SpringBootApplication注释配置类。 |
引导过程通过向主节点注入初始化器结束SpringApplication实例（即正常的 Spring Boot 启动序列，无论作为独立应用程序运行还是部署在应用服务器中）。
首先，从以下类别创建引导上下文Spring。工厂.
然后，全部@Beans类型应用上下文初始化器被添加到主SpringApplication在开始之前。
自定义Bootstrap属性来源
引导进程添加的外部配置默认属性源是 Spring Cloud 配置服务器，但你也可以通过添加 Beans 来添加额外的源PropertySourceLocator通过引导式上下文（通过）Spring。工厂).
例如，你可以从不同的服务器或数据库中插入额外的属性。
举例来说，考虑以下自定义定位器：
@Configuration
public class CustomPropertySourceLocator implements PropertySourceLocator {
@Override
public PropertySource<?> locate(Environment environment) {
return new MapPropertySource("customProperty",
Collections.<String, Object>singletonMap("property.from.sample.custom.source", "worked as intended"));
}
}这环境传递的 是应用上下文即将被创造——换句话说，就是我们为其提供额外财产来源的那个。
它已经有 Spring Boot 提供的属性源，所以你可以用这些来查找专门针对这个的属性源环境（例如，通过键化spring.application.name，与默认的Spring Cloud Config服务器属性源定位器相同。
如果你创建一个包含该类的jar，然后添加一个META-INF/spring.factories包含以下设定，customProperty（定制财产） 地产来源出现在任何包含该jar的类路径应用中：
org.springframework.cloud.bootstrap.BootstrapConfiguration=sample.custom.CustomPropertySourceLocator自 Spring Cloud 2022.0.3 起，Spring Cloud 将开始调用PropertySourceLocators两次。第一次接球
会检索任何没有配置文件的属性源。这些房地产来源将有机会
启用配置文件春季.档案.活跃.主应用上下文开始后PropertySourceLocators将会第二次被召唤，这次只要有活跃的资料允许PropertySourceLocators定位
任何其他地产来源有侧写。
日志配置
如果你用 Spring Boot 配置日志设置，应该把这个配置放在启动。[yml | 属性]如果你希望它适用于所有活动。
为了让 Spring Cloud 正确初始化日志配置，你不能使用自定义前缀。
例如，使用自定义.loggin.logpath在初始化日志系统时，Spring Cloud 无法识别。 |
环境变化
应用程序会监听环境变迁事件并以几种标准方式对变化做出反应（附加内容）ApplicationListeners可以添加为@Beans以正常方式）。
当环境变迁事件观察到，它包含一个变更的键值列表，应用程序利用这些值来：
-
重新绑定任何
@ConfigurationProperties豆子在语境中。 -
为 中任何属性设置日志值
logging.level.*.
请注意，Spring Cloud 配置客户端默认不会轮询环境.
一般来说，我们不推荐这种方法来检测变化（虽然你可以用@Scheduled注释）。
如果你的客户端应用规模扩大，最好广播环境变迁事件对所有实例进行轮询，而不是让它们轮询变更（例如，通过使用 Spring Cloud 总线）。
这环境变迁事件只要你能对环境并发布该活动。
请注意，这些API是公开的，是Spring核心的一部分。
你可以验证这些变更是否绑定于@ConfigurationProperties通过访问/configprops端点（Spring Boot Actuator的标准功能）。
例如，a数据来源可以有其最大池大小运行时更改（默认数据来源由Spring Boot创造的@ConfigurationProperties豆子）并动态增长产能。
重新装订@ConfigurationProperties这并未涵盖另一大类用例，比如需要对刷新更严格的控制，以及需要对整个更新进行原子级更改应用上下文.
为了解决这些担忧，我们有@RefreshScope.
Java 记录注释为@ConfigurationProperties无法刷新。 |
刷新范围
当配置发生变化时，Spring@Bean标记为@RefreshScope获得特殊待遇。
该功能解决了有状态豆子仅在初始化时才被注入配置的问题。
例如，如果数据来源当通过环境你可能希望这些连接的持有者能够完成他们正在做的事情。
然后，下次当某物从池中借用连接时，它会获得带有新网址的连接。
有时，甚至可能必须应用@RefreshScope有些豆子只能初始化一次。
如果豆子是“不可变”的，你必须给豆子做注释@RefreshScope或者在属性键下指定类名：spring.cloud.refresh.extra-refreshable.
如果你有数据来源豆子，那是光数据源，不可能是
刷新。它是 的默认值spring.cloud.refresh.never-refreshable.选择一个
不同数据来源如果你需要刷新，实现也可以。 |
刷新范围豆是懒惰代理，在使用时初始化（即调用方法时），作用域作为初始化值的缓存。 要强制豆子在下一次方法调用时重新初始化，必须使其缓存条目失效。
这RefreshScope（刷新视野）在语境中是豆子，且具有公共refreshAll（）通过清除目标缓存来刷新作用域中的所有豆子的方法。 这/刷新端点通过HTTP或JMX暴露此功能。要按名称刷新单个豆子，还有一个refresh（String）方法。
为了揭露/刷新端点，您需要为您的应用程序添加以下配置：
management:
endpoints:
web:
exposure:
include: refresh
@RefreshScope技术上可以@Configuration但这可能导致令人意外的行为。例如，这并不意味着所有@Beans定义在该类中 的 本身属于@RefreshScope. 具体来说，任何依赖这些豆子的东西都不能指望它们在刷新启动时自动更新，除非它本身已经在@RefreshScope. 在这种情况下，它会在刷新时重建，并重新注入其依赖。此时，依赖关系会从刷新后重新初始化@Configuration). |
| 删除配置值后再执行刷新不会更新该配置值的存在。必须配置属性存在，才能在刷新后更新该值。如果你依赖应用中的某个值的存在，你可能需要将逻辑切换为依赖该值的缺失。另一种选择是依赖该值的变化，而不是在应用配置中不存在。 |
Spring AOT 变换和原生图像不支持 Context Refresh。对于 AOT 和原生图像，spring.cloud.refresh.enabled需要设置为false. |
重启时刷新范围
在重启时无缝刷新豆子对于运行JVM Checkpoint Restore的应用程序（如Project CRaC）尤其有用。为了实现这一功能，我们现在实例化一个RefreshScope生命周期该豆在重启时触发上下文刷新，导致配置属性重新绑定并刷新任何标注为@RefreshScope. 你可以通过设置来禁用这种行为spring.cloud.refresh.on-restart.enabled自false.
加密与解密
春云有环境用于本地解密属性值的预处理器。它遵循与 Spring Cloud 配置服务器相同的规则，并通过以下方式实现相同的外部配置加密。*. 因此，你可以使用以下形式的加密值{密码}*，只要存在有效的密钥，它们会在主应用上下文获得环境设置。 要在应用中使用加密功能，你需要在类路径中包含 Spring Security RSA（Maven 坐标：org.springframework.security：spring-security-rsa），你还需要在JVM中安装全强度的JCE扩展。
如果你因“非法密钥大小”获得例外，并且使用Sun的JDK，你需要安装Java密码扩展（JCE）的无限强度管辖权政策文件。更多信息请参见以下链接：
把文件解压到你使用的 JRE/JDK x64/x86 版本的 JDK/jre/lib/security 文件夹里。
端点
对于 Spring Boot Actuator 应用程序，还提供一些额外的管理端点。您可以使用：
-
发布自/执行器/环境以更新环境并重新绑定@ConfigurationProperties以及日志级别。要启用该端点，你必须设置Management.Endpoint.env.Post.enabled=true. -
/执行器/刷新重新加载引导链上下文并刷新@RefreshScope豆。 -
/执行器/重启关闭应用上下文然后重启（默认禁用）。 -
/执行器/暂停和/执行器/简历为了呼叫生命周期方法 （停止（）和开始（）在应用上下文).
同时启用发布方法/执行器/环境端点可以为管理应用环境变量提供灵活性和便利性，确保端点受到安全和监控至关重要，以防止潜在的安全风险。添加 aSpring Boot启动依赖配置执行器端点的访问控制。 |
如果你禁用了/执行器/重启端点，则/执行器/暂停和/执行器/简历端点 也会被禁用，因为它们只是/执行器/重启. |