小菜鸟

解决 Spring Cloud Config Server 单点问题：基于服务发现的高可用方案

Spring Cloud Config Server 作为分布式配置中心，若采用单点部署，一旦服务宕机，所有依赖它的客户端将无法获取配置，导致系统故障。通过将 Config Server 注册到服务发现组件（如 Eureka、Nacos），可实现其高可用部署，避免单点风险。

单点问题的根源与解决方案

问题表现

客户端通过固定的uri配置连接 Config Server：

1
2
3
4

spring:
  cloud:
    config:
      uri: http://localhost:7010  # 固定地址，存在单点风险

当localhost:7010的 Config Server 宕机后，客户端无法切换到其他实例，导致配置获取失败。

解决方案

利用服务发现机制，将多个 Config Server 实例注册到服务中心，客户端通过服务名而非固定地址访问，实现自动负载均衡和故障转移：

1. 部署多个 Config Server 实例并注册到服务中心；
2. 客户端通过服务名从服务中心获取 Config Server 地址；
3. 客户端与 Config Server 之间通过负载均衡建立连接。

基于 Eureka 的 Config Server 高可用配置

以下以 Eureka 作为服务发现组件，详细说明配置步骤：

Spring Cloud Config 配置存储机制：从本地文件到 Git 仓库

Spring Cloud Config 作为分布式配置中心，支持多种配置存储方式，核心通过 EnvironmentRepository 接口实现配置的读取与管理。不同的存储方式对应不同的 EnvironmentRepository 实现，其中最常用的是本地文件存储和Git 仓库存储。

EnvironmentRepository：配置存储的核心接口

EnvironmentRepository 是 Spring Cloud Config 中配置存储的顶层接口，定义了获取配置的核心方法：

1
2
3
4

public interface EnvironmentRepository {
    // 根据应用名、环境、分支获取配置
    Environment findOne(String application, String profile, String label);
}

Environment 类是配置数据的载体，包含以下核心字段：

• name：应用名（对应 spring.application.name）；
• profiles：环境（如 dev、prod）；
• label：分支（如 Git 分支 master）；
• version：配置版本（如 Git 提交哈希）；
• propertySources：配置键值对集合。

基于本地文件的配置存储（NativeEnvironmentRepository）

当配置中心需要从本地文件系统读取配置时，使用 NativeEnvironmentRepository 实现，适用于开发环境或无版本控制需求的场景。

启用本地文件存储

需通过 spring.profiles.active=native 激活本地存储模式：

RestTemplate 拦截器（ClientHttpRequestInterceptor）详解与实践

RestTemplate 的拦截器机制允许我们在 HTTP 请求发送前和响应返回后进行自定义处理，非常适合实现日志记录、请求头添加、认证信息附加等横切关注点功能。

ClientHttpRequestInterceptor 核心原理

ClientHttpRequestInterceptor 是 RestTemplate 的拦截器接口，其核心方法 intercept 会在请求执行前后被调用：

1
2
3
4
5
6
7

public interface ClientHttpRequestInterceptor {
    ClientHttpResponse intercept(
        HttpRequest request, 
        byte[] body, 
        ClientHttpRequestExecution execution
    ) throws IOException;
}

• request：即将发送的 HTTP 请求对象，可修改请求头、请求方法等
• body：请求体内容
• execution：执行器，调用其 execute 方法继续请求链的执行

拦截器的执行流程如下：

序列化方式

序列化是将对象的状态信息转换为可存储或传输形式的过程，在分布式系统、数据存储、网络通信等场景中至关重要。以下是常见序列化方式的详细梳理，包括其特点、适用场景等：

1. Java 默认序列化

• 原理：通过实现 Serializable 接口，使用 Java 自带的序列化机制将对象转换为字节流。
• 特点：
  • 缺点明显：仅支持 Java 语言，无法跨语言交互；序列化后数据体积大，性能较差（反射机制导致）；存在安全漏洞（反序列化可能执行恶意代码）。
  • 优点：无需额外依赖，Java 原生支持。
• 适用场景：仅适用于简单的 Java 单机或内部系统，不推荐在分布式、跨语言场景中使用。

2. XML

• 原理：基于标签的文本格式，通过标签结构描述数据类型和值。
• 特点：
  • 优点：可读性极强，结构清晰，支持复杂数据类型（如嵌套、数组），广泛用于配置文件（如 Spring 配置）和数据交换。
  • 缺点：标签冗余导致序列化后数据体积大，解析速度慢（需解析大量标签），格式复杂。
• 适用场景：配置文件（如 pom.xml）、跨平台数据交换（如早期 SOAP 协议），但逐渐被 JSON 替代。

3. JSON

• 原理：轻量级文本格式，使用键值对（key-value）和数组结构描述数据。
• 特点：
  • 优点：兼容性好（跨语言支持广泛），数据格式简单，序列化后体积比 XML 小，解析速度快；可读性适中。
  • 缺点：性能不足以满足毫秒级（ms）响应要求，不适合超高性能场景；不支持二进制数据（需转义为 Base64，增加体积）。
• 适用场景：小数据量网络传输（如 RESTful API）、日志存储、前端与后端交互，可满足秒级响应的服务需求。

Bootstrap 配置详解

Bootstrap 配置是 Spring Cloud 中一个特殊的配置机制，它先于 Spring Boot 的常规配置加载，主要用于初始化 Spring Cloud 相关的上下文环境。以下从配置加载流程、核心特性及使用注意事项展开说明：

Bootstrap 配置的加载触发机制

Bootstrap 配置的加载由BootstrapApplicationListener监听器主导，具体流程如下：

1. 事件触发：监听 Spring 应用启动时的ApplicationEnvironmentPreparedEvent事件（此时环境变量已准备，但 Spring 容器尚未创建）。
2. 环境准备：通过prepareEnvironment(listeners, applicationArguments)方法初始化环境，优先加载 Bootstrap 配置。
3. 启用开关：可通过spring.cloud.bootstrap.enabled属性控制是否启用 Bootstrap 配置，默认值为true。若设置为false，则跳过 Bootstrap 配置加载流程，直接进入 Spring Boot 常规配置阶段。

配置文件的命名与自定义