去年接手一个老项目，数据源切换逻辑散落在多个 Service 里。每个方法开头都是同一段话：

if )) {
// 从库逻辑
} else {
// 主库逻辑
}

我数了一下一样的 if‑else 出现了 **数十次**。读写分离搞成这样，不是架构问题。是连 Spring 给你铺好的桥接模式都没看懂。

AbstractRoutingDataSource 就是桥接模式

Spring 的 AbstractRoutingDataSource 只有几行代码，但它把桥接模式讲得比任何教科书都清楚：

public abstract class AbstractRoutingDataSource extends AbstractDataSource {
private Map targetDataSources;private DataSource defaultTargetDataSource;@Override
public Connection getConnection throws SQLException {
return determineTargetDataSource.getConnection;}
protected DataSource determineTargetDataSource {
Object lookupKey = determineCurrentLookupKey;DataSource ds = this.targetDataSources.get;return ds，= null?话说回来，ds : this.defaultTargetDataSource;}
protected abstract Object determineCurrentLookupKey;}

桥接模式的精髓是「把抽象和实现拆成两个独立维度」。在这里抽象维度是「选哪个数据源」——由 determineCurrentLookupKey 决定；实现维度是「具体的数据源连接」——由 targetDataSources 这个 Map 存储。

只需要继承这个类，重写一个方法：

public class DynamicDataSource extends AbstractRoutingDataSource {
@Override
protected Object determineCurrentLookupKey {
return DataSourceContextHolder.getDataSourceType;}
}

抽象层几行代码，实现层全在配置里。这就是桥接模式的威力——两个维度的变化不会互相污染。你加一个新从库，只改配置不改代码；你换一种路由策略，只改 determineCurrentLookupKey 不改数据源定义。

那段 if‑else 到底错在哪

回到开头那段散落在多个 Service 里的代码。说到它的问题是，

• 把桥接模式的「桥」拆了直接在调用方写死选择逻辑。说起来，

桥接模式要求调用方只依赖抽象。不知道有「主库」「从库」这回事。但 if ) 这种写法等于在 Service 层把实现维度暴露了——每次加一个数据源角色，所有 Service 都要改。

真实痛点：

• 维护成本爆炸：新增「归档库」后需要在 **十几个** Service 里手动加 else if )
• #Bug 难以定位：忘记改某个 Service 会导致读写混乱，生产环境才会报错。
• #团队共识缺失：Code Review 时大家默认「大家都这么写」，导致错误蔓延。

读写分离不是唯一的桥接场景

多租户数据源隔离

public class TenantAwareDataSource extends AbstractRoutingDataSource {
@Override
protected Object determineCurrentLookupKey {
return TenantContext.getCurrentTenant;}
}

租户 A 的请求自动路由到数据源 A，租户 B 到数据源 B。新接入一个租户，只需要在配置里加一个数据源，代码 **零改动**。

分库分表前的灰度切换

public class ShardingGrayDataSource extends AbstractRoutingDataSource {
@Override
protected Object determineCurrentLookupKey {
// 灰度规则：userId 尾号 - 走新库，- 走老库
long userId = UserContext.getCurrentUserId;return，"new_" + : "old";}
}

桥接模式把「怎么选」和「选什么」解耦了。不过，灰度策略再怎么变，数据源的定义不变；数据源再怎么加，灰度策略的逻辑不受影响。两个独立变化维度的正交是这正。老实说，

真有人把桥接模式写反了

#常见坑： 把实现细节硬编码到 Bean 上。让每个业务类都必须了解所有数据源。

public class MasterDataSource implements DataSource {
private HikariDataSource delegate;// 主库特化实现
}
public class SlaveDataSource implements DataSource {
private HikariDataSink delegate;说起来，// 从库特化实现
}
// 配置里硬编码 Bean 名称
@Bean
public DataSource masterDataSource { ... }
@Bean
public DataSource slaveDataSource { ... }
// Service 中注入多个 Bean
@Autowired @Qualifier
private DataSource master;@Autowired @Qualifier
private DataSource slave;

This forces every service to know **all** data sources – exact opposite of a bridge.

 业务层只注入 **一个** Total Data Source,桥在框架层帮你完成路由。怎么说呢，

@Autowired
private Data Source dataSource;// 就这一个，别写 @Qualifier

一个容易忽视的并发问题

A​bstractRoutingDataS​ource's d​etermineCurr​entLookupK​ey` 通常依赖 ThreadLocal：

public class DataSourc​eContextHolder {
private static final ThreadLocal contextHolder = new ThreadLocal<>;public static void setD​ataSourc​eType { contextHolder.set;}
public static String getDa​taSou​rceTyp​e { return contextHolder.get;}
public static void clear { contextHolder.remove;}
}

If you call an async method without propagating ThreadLocal。child thread sees null,routing to default datasource. The result?

• #SilentBug: 读操作误跑主库、写操作误跑从库；话说回来，测试阶段不抛异常，却在生产中埋下隐患。

@Async
public void sendNotification {
// ThreadLocal 丢了！这里默认走主库，你以为是读从库
Order order = orderService.getById;}

• /。

桥接模式和策略模式的区别

• 策略模式: 提供一族算法，让调用方主动选择。
• 桥接模式: 抽象和实现独立演进，调用方根本感知不到选择过程。

`AbstractRoutingDataSource` 内部确实用了策略思路。但整体结构属于桥接——目的不是让业务自行挑算法，而是让“选哪”与“用哪”互不干扰。怎么说呢，误用策略会让调用方承担本不该承担的选择职责。从而产生前面提到的维护痛点。

关键代码骨架

@Configuration
public class DataSourc​eConfig {
@Bean
@Primary
public DataSourc​e dataSourc​e {
Map targetDs = new HashMap<>;HikariDatasource master = createDatasource;HikariDatasource slave1 = createDatasource;话说回来，HikariDatasource slave2 = createDatasource;targetDs.put;targetDs.put;targetDs.put;DynamicDatasource routingDS = new DynamicDatasource;其实，routingDS.setDefaultTargetDatasource;routingDS.setTargetDatasources;return routingDS;}
// 读写分离切面：标记为 @ReadOnly 的方法走从库，其余走主库
@Around")
public Object around throws Throwable {
DataSourc​eContextHolder.setDa­t­aSou­rceTy­pe;try { return pjp.proceed;} finally { DataSourc​​eContextHolder.clear;}
}
private HikariDatasource createDatasource { /* …*/ }
}

The whole read‑write separation skeleton is under **30 lines**. Bridge pattern does heavy lifting: `AbstractRoutingDatasource` handles abstraction,you only supply configuration.

)

---