application.yaml与bootstrap.yaml的使用_Bootstrap

application.yaml与bootstrap.yaml

你对这两个文件有没有清晰认识？

application.yaml

用途：主要用于应用程序的主要配置，包括数据库连接信息、端口号、日志级别、自定义属性等应用级别的设置。这是spring boot应用中最常见的配置文件，几乎所有自定义配置都会放在这里。
加载时机：application.yaml 在spring应用上下文初始化之后被加载，这意味着大部分bean的创建和自动配置都会考虑到这里的配置信息。
覆盖：可以通过命令行参数、环境变量、java系统属性等方式覆盖application.yaml中的配置。

bootstrap.yaml

用途：主要用于应用程序的引导阶段配置，特别是与spring cloud相关的配置，如配置中心（config server）的地址。它的内容在应用程序的上下文初始化之前被加载，适合配置那些需要在spring应用上下文启动之前就需要读取的属性，比如用来配置从何处加载主配置文件的地址。
加载时机：bootstrap.yaml 文件比application.yaml更早加载，它在应用程序的引导阶段就被处理，用于应用程序上下文初始化之前的配置，比如配置中心的配置。
用途示例：当使用spring cloud config server来集中管理配置时，你需要在bootstrap.yaml中配置config server的地址，这样spring cloud会先从config server获取配置信息，再初始化spring boot应用。

这两大段在讲什么不能简单讲一下吗？

知识储备

bean：实现控制反转的一个java对象加入到ioc容器当中
spring上下文：bean管理资源访问消息传递生命周期管理我就简单讲一下第一个【第一个最好讲】 bean管理： applicationcontext 读取配置元数据（xml文件 java配置注解）根据这些数据创建bean 实现控制反转

spring上下文启动：加载配置 -》 bean读取 -》 bean的实例化 -》 bean的初始化 -》启动后监听

容器初始化阶段（加载配置阶段） springboot 会读取 application.yaml 文件

bootstrap.yaml 文件在加载配置阶段前就已经读取了

bootstrap.yaml 更早加载，主要用于引导配置，影响整个应用的初始化；而 application.yaml 加载较晚，负责应用的主体配置，灵活性和可覆盖性更高。

我们来举例

bootstrap配置文件在spring boot应用的启动过程中比application配置文件具有更高的优先级。

这意味着在应用初始化的最早阶段，spring会先读取bootstrap文件中的配置。

由于nacos作为配置中心，负责提供应用运行时所需的配置信息，将其地址放在bootstrap中可以确保应用在加载其他任何配置或初始化bean之前就能建立起与nacos的连接，从而能够及时获取到所有必需的配置。

server:
  port: 3000 # 前端默认访问端口号为3000
  servlet:
    context-path: / # 前端默认访问的根路径
spring:
  application:
    name: gateway-service  # 程序名就是服务名
  cloud:
    nacos:      
        server-addr: 174.148.4.170:8848 #注册中心

当然还有其他原因：

功能隔离：bootstrap配置主要用于应用程序的引导阶段，它配置的内容是用来引导spring boot应用上下文的创建，比如配置中心的地址、安全证书、加密解密的密钥等基础设施级别的设置。而application配置则是关于应用本身的业务逻辑和特性配置。将nacos地址这样的基础设施配置与业务逻辑配置分离开来，有助于清晰地组织配置，同时也便于管理和维护。
安全性与稳定性：将与配置中心通信的敏感信息和基础配置放在bootstrap中，可以减少这些关键信息被不当覆盖的风险，因为bootstrap的配置不容易被外部环境变量或其他配置源所覆盖。这对于生产环境尤其重要，保证了系统的稳定性和安全性。
避免循环依赖：如果nacos配置包含了应用运行所必需的参数（比如数据库连接字符串），而这些参数又存储在nacos中，那么必须在应用启动时就正确设置nacos的地址以获取这些参数，避免因配置加载顺序导致的潜在循环依赖问题

在来看一下3：想象一下，你的spring boot应用需要从nacos获取数据库连接字符串等关键配置来初始化数据库访问组件（如datasource）。然而，这些数据库连接信息实际上是存储在nacos中的。

这就形成了一个逻辑上的依赖链：应用启动 -> 连接nacos -> 获取数据库配置 -> 初始化数据库连接。如果nacos的地址或者连接nacos所需的其他关键参数（如认证信息）也打算通过nacos来管理，那么就会出现问题，因为这时应用在没有nacos配置的情况下无法知道如何连接到nacos以获取这些配置信息，形成了一种“鸡生蛋，蛋生鸡”的困境，即循环依赖。