如何配置Spring Cloud Config实现多后端读单后端写？

1. 多后端读写分离配置（只读Native + 可写JDBC） #

完全可行，Spring Cloud Config原生支持多后端组合，通过以下配置即可实现从双后端读取配置，仅写入JDBC后端：

spring:
  profiles:
    active: jdbc,native
  cloud:
    config:
      server:
        jdbc:
          read-only: false  # 允许写入操作
          sql: "SELECT KEY, VALUE from ACM_CLOUDCONFIG where APPLICATION = ? and PROFILE = ? and LABEL = ?"
          order: 1  # 优先级更高，相同配置键会覆盖Native后端内容
        native:
          read-only: true  # 强制只读，拒绝写入请求
          search-locations: "file:///path/to/your/local/configs"
          order: 0  # 优先级较低

关键逻辑说明： #

• 读取阶段：Config Server会从所有激活的后端加载配置，按order值从大到小合并（值越大优先级越高），若Native和JDBC存在相同配置键，JDBC的内容会覆盖Native的。
• 写入阶段：当客户端提交配置修改时，Config Server会检查后端的read-only属性，Native后端因设为true会拒绝写入请求，所有修改自动路由到可写的JDBC后端。

2. 让"modified" Profile仅绑定JDBC后端 #

原生Spring Cloud Config没有直接的profilePattern配置，但可以通过两种方式实现：

方案一：Native后端排除"modified" Profile #

修改Native后端的搜索路径，仅加载非"modified"的配置文件，确保application-modified.yml仅存在于JDBC中：

spring:
  cloud:
    config:
      server:
        native:
          search-locations: "file:///path/to/configs/application-*.yml, !file:///path/to/configs/application-modified.yml"

通过!符号排除modified相关配置文件，Native后端不会加载该Profile内容，只有JDBC后端会处理。

方案二：自定义EnvironmentRepository路由逻辑 #

如果需要更灵活的Profile路由，可以自定义EnvironmentRepository实现，根据请求的Profile判断后端来源：

@Component
public class RoutingEnvironmentRepository implements EnvironmentRepository {

    @Autowired
    private JdbcEnvironmentRepository jdbcRepo;
    @Autowired
    private NativeEnvironmentRepository nativeRepo;

    @Override
    public Environment findOne(String application, String profile, String label) {
        if (profile.contains("modified")) {
            // 仅从JDBC读取modified profile
            return jdbcRepo.findOne(application, profile, label);
        } else {
            // 合并Native和JDBC的非modified profile
            Environment nativeEnv = nativeRepo.findOne(application, profile, label);
            Environment jdbcEnv = jdbcRepo.findOne(application, profile, label);
            return Environment.merge(nativeEnv, jdbcEnv);
        }
    }
}

这种方式可精确控制不同Profile的后端来源，同时保留写入时仅JDBC可写的逻辑。

3. 集群化部署适配 #

你的需求（避免文件并发损坏、无需Git HA）可通过以下方式满足：

• JDBC后端：使用支持HA的数据库集群（如MySQL主从、PostgreSQL流复制），Config Server集群节点共享同一个数据库，天然解决写入一致性问题。
• Native后端：因为是只读模式，每个Config Server节点可本地存储一份相同的配置文件，通过自动化工具（如Ansible、Docker镜像打包）定期同步更新，无需共享存储，彻底避免并发写入风险。

内容的提问来源于stack exchange，提问作者Diego Rivera