小菜鸟

Spring 双数据源配置与动态切换全指南

在企业级开发中，双数据源（或多数据源）是常见需求，例如 “主业务数据存库 A，特殊业务数据存库 B”。Spring 提供了 AbstractRoutingDataSource 抽象类实现数据源动态路由，配合 AOP 可实现 “注解式切换数据源”。从 “数据源配置→动态路由→AOP 切换→事务注意事项” 四个维度，详解双数据源的实现原理与最佳实践。

双数据源核心原理

Spring 动态数据源的核心是 AbstractRoutingDataSource（抽象路由数据源），其工作流程如下：

1. 维护数据源映射：内部通过 targetDataSources 存储 “数据源 Key → 数据源实例” 的映射，通过 defaultTargetDataSource 指定默认数据源；
2. 动态路由：当执行数据库操作时，调用 determineCurrentLookupKey() 方法获取当前数据源 Key；
3. 获取数据源：根据 Key 从 targetDataSources 中匹配对应的数据源，若无匹配则使用默认数据源。

简单来说，AbstractRoutingDataSource 相当于一个 “数据源路由器”，通过 Key 决定当前使用哪个数据源。

双数据源配置步骤（XML 方式）

以 Druid 连接池为例，完整配置包括 “基础数据源配置→动态数据源配置→连接池与事务配置”。

1. 步骤 1：引入依赖（Maven）

需引入 Druid 连接池、Spring JDBC、事务、AOP 相关依赖：

Spring Cloud Config 远程配置获取流程：客户端与服务端交互详解

Spring Cloud Config 的核心能力是实现配置的远程管理与分发，其底层通过客户端主动拉取和服务端按需提供的方式完成配置交互。本文从客户端和服务端两方面，结合源码解析远程配置的获取全流程。

客户端（Config Client）获取远程配置的流程

客户端获取远程配置的核心是 PropertySourceLocator 接口，其实现类 ConfigServicePropertySourceLocator 负责与服务端通信并拉取配置。

核心接口：PropertySourceLocator

PropertySourceLocator 是 Spring Cloud 定义的配置源定位接口，用于从远程（如 Config Server）或本地加载配置，核心方法为 locate：

1
2
3
4

public interface PropertySourceLocator {
    // 定位并返回配置源（PropertySource）
    PropertySource<?> locate(Environment environment);
}

Spring Cloud Config 客户端通过 ConfigServicePropertySourceLocator 实现该接口，完成远程配置拉取。

客户端拉取配置的触发时机

客户端配置拉取发生在 Spring Boot 启动的早期阶段（ Bootstrap 阶段），由以下组件协同触发：

（1）Bootstrap 上下文初始化

Spring Cloud 会创建一个独立的 Bootstrap Context（ Bootstrap 上下文），作为应用主上下文的父上下文，专门用于加载远程配置。其初始化由 BootstrapApplicationListener 监听器触发：

ShardingSphere-JDBC水平分库分表

ShardingSphere-JDBC水平分库分表非常简单，只需要添加ShardingSphere-JDBC依赖并进行配置即可

1
2
3
4
5
6

<!-- sharding-jdbc 分库分表 -->
<dependency>
    <groupId>org.apache.shardingsphere</groupId>
    <artifactId>sharding-jdbc-spring-boot-starter</artifactId>
    <version>4.1.0</version>
</dependency>

Hystrix 隔离策略：线程隔离与信号量隔离的深度解析

在分布式系统中，服务间依赖可能因网络延迟、资源耗尽等原因出现故障。Hystrix 通过隔离策略限制故障影响范围，防止单个依赖拖垮整个系统。其核心隔离策略有两种：线程隔离（THREAD） 和信号量隔离（SEMAPHORE），适用于不同场景，各有优劣。

隔离策略的核心目标

隔离的本质是限制依赖服务对系统资源（线程、CPU 等）的占用，避免 “一个依赖故障导致全局崩溃”。具体目标包括：

1. 防止依赖服务的高延迟或故障占用过多线程资源；
2. 控制依赖服务的并发量，避免超出其承载能力；
3. 当依赖故障时，快速失败并触发降级，减少对调用方的影响。

线程隔离（THREAD）：彻底的资源隔离

线程隔离是 Hystrix 的默认策略，通过为每个依赖服务分配独立线程池实现隔离。调用依赖服务的逻辑在独立线程中执行，与调用方线程（如 Tomcat 的工作线程）完全分离。

实现原理

• 独立线程池：每个依赖服务（或分组）对应一个线程池，线程池参数（核心线程数、队列大小等）可单独配置；
• 调用流程：调用方线程将请求提交到线程池后立即返回，由线程池中的线程执行依赖调用；
• 资源隔离：线程池的线程数和队列长度限制了对该依赖的最大并发量，避免占用调用方的主线程资源。

Maven 环境配置：多环境管理与灵活激活策略

在实际开发中，项目通常需要在本地、开发、测试、生产等多环境中部署，而不同环境的配置（如数据库地址、端口、依赖版本）往往存在差异。Maven 提供了 profile 机制来管理多环境配置，支持灵活的激活方式，确保在不同环境下的构建一致性。本文将详细介绍 Maven 环境配置的实现与最佳实践。

什么是 Maven Profile？

profile 是 Maven 中用于区分环境配置的机制，可在不同环境下启用不同的属性、依赖、插件或构建规则。每个 profile 通过唯一 id 标识，可包含以下内容：

• 自定义属性（如 profileActive=dev）。
• 依赖管理（如不同环境引入不同版本的 Jar 包）。
• 插件配置（如生产环境跳过测试，开发环境启用调试）。
• 仓库配置（如开发环境使用私服，生产环境使用中央仓库）。

Profile 配置方式

Maven 支持在两个位置配置 profile：项目的 pom.xml 和 全局的 settings.xml，两者适用场景不同。

在 pom.xml 中配置（项目级）

适合项目专属的环境配置（如项目特有的数据库地址、端口），配置直接位于项目 pom.xml 的 <profiles> 标签中。

示例：区分本地、开发、测试、生产环境：