Spring Cloud 配置中心选型实战：Nacos vs Apollo vs Spring Cloud Config

2.1.2 客户端配置

第一步：引入依赖

<dependencies>
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-config</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-actuator</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
    </dependency>
</dependencies>

第二步：编写 bootstrap.yml

spring:
  application:
    name: user-service
  cloud:
    config:
      label: master
      profile: dev
      uri: http://localhost:8888/
      name: user
    eureka:
      client:
        service-url:
          defaultZone: http://localhost:8761/eureka/
  management:
    endpoints:
      web:
        exposure:
          include: refresh

第三步：动态刷新配置

在需要动态刷新的类上添加 @RefreshScope 注解：

@RestController
@RefreshScope
public class UserController {
    @Value("${user.name}")
    private String userName;

    @GetMapping("/user/name")
    public String getUserName() {
        return userName;
    }
}

修改 Git 仓库中的配置后，调用 POST http://localhost:端口/actuator/refresh 接口触发刷新。

2.1.3 局限性总结

1. 动态刷新繁琐：需配合 Bus 实现批量刷新，否则需逐个服务调用接口。
2. 无可视化界面：配置修改需操作 Git 仓库，对非技术人员不友好。
3. 功能单一：仅支持配置管理，无服务发现等附加能力。

2.2 Apollo

Apollo 是携程开源的分布式配置中心，专为企业级场景设计，提供了完善的权限管控、灰度发布、配置审计等能力。

2.2.1 核心架构原理

Apollo 采用多组件分布式架构，核心组件包括：

• Portal：配置管理门户，提供可视化界面。
• Admin Service：配置管理服务，处理配置的修改、发布请求。
• Config Service：配置查询服务，提供配置拉取接口。
• Client：客户端 SDK，嵌入微服务中。

2.2.2 客户端配置

第一步：引入依赖

<dependency>
    <groupId>com.ctrip.framework.apollo</groupId>
    <artifactId>apollo-client</artifactId>
    <version>2.0.0</version>
</dependency>

第二步：编写 application.yml

app:
  id: user-service
apollo:
  meta: http://localhost:8080
  bootstrap:
    enabled: true
    namespaces: application,user-service.common
  environment: dev

第三步：使用配置

Apollo 支持自动注入配置，无需额外注解：

@RestController
public class UserController {
    @Value("${user.name}")
    private String userName;

    @GetMapping("/user/name")
    public String getUserName() {
        return userName;
    }
}

配置修改并发布后，客户端会实时感知变更，无需调用刷新接口。

2.2.3 局限性总结

1. 部署复杂：需部署多个组件（Portal、Admin Service、Config Service），对运维要求较高。
2. 资源消耗较高：多组件架构占用更多服务器资源，不适合小型项目。

2.3 Nacos

Nacos 是阿里巴巴开源的动态服务发现、配置管理和服务管理平台，最大特点是集配置中心和注册中心于一体。

2.3.1 核心架构原理

Nacos 采用极简的分布式架构，支持 AP（高可用）和 CP（强一致性）模式切换，核心组件只有服务端和客户端：

• Nacos Server：服务端，提供配置管理和服务发现的核心能力。
• Nacos Client：客户端，嵌入微服务中。

Nacos 的配置存储支持嵌入式数据库 Derby（单机模式）和 MySQL（集群模式）。

2.3.2 核心特性

• 配置 + 注册一体化：一套组件解决配置管理和服务发现两个核心问题。
• 动态配置刷新：支持配置实时推送，客户端自动感知变更。
• AP/CP 切换：服务发现支持 AP/CP 模式切换。
• 可视化界面：内置功能完善的控制台。
• 部署简单：单机模式一键启动。

2.3.3 实战配置

第一步：部署 Nacos Server

1. 下载 Nacos 安装包，解压后进入 bin 目录。
2. 单机模式启动：sh startup.sh -m standalone（Linux）或 startup.cmd -m standalone（Windows）。
3. 访问控制台：http://localhost:8848/nacos，默认账号 / 密码：nacos/nacos。

第二步：客户端集成配置

引入依赖

<dependencies>
    <dependency>
        <groupId>com.alibaba.cloud</groupId>
        <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
    </dependency>
    <dependency>
        <groupId>com.alibaba.cloud</groupId>
        <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
    </dependency>
</dependencies>

编写 bootstrap.yml

spring:
  application:
    name: user-service
  cloud:
    nacos:
      discovery:
        server-addr: localhost:8848
      config:
        server-addr: localhost:8848
        file-extension: yml
        namespace: dev
        group: DEFAULT_GROUP

使用配置

添加 @RefreshScope 注解实现动态刷新：

@RestController
@RefreshScope
public class UserController {
    @Value("${user.name}")
    private String userName;

    @GetMapping("/user/name")
    public String getUserName() {
        return userName;
    }
}

在 Nacos 控制台修改配置并发布后，客户端会自动刷新配置。

2.3.4 局限性总结

1. 企业级特性略弱：权限管控和灰度发布功能不如 Apollo 完善（需付费版支持更高级特性）。
2. 高并发场景优化需手动配置：集群模式下的性能优化需要一定的运维经验。

3. 全方位对比

为了更直观地展示三款配置中心的差异，我们从 11 个核心维度进行深度对比：

4. 迁移方案与避坑指南

4.1 从 Spring Cloud Config 切换到 Nacos

步骤 1：引入 Nacos 依赖，移除 Config 依赖

将原有的 spring-cloud-starter-config 替换为 spring-cloud-starter-alibaba-nacos-config。

步骤 2：修改配置文件

将 bootstrap.yml 中的 Config 配置替换为 Nacos 配置：

spring:
  application:
    name: user-service
  cloud:
    # 移除 Config 配置
    # config:
    #   label: master
    #   profile: dev
    #   uri: http://localhost:8888/
    nacos:
      discovery:
        server-addr: localhost:8848
      config:
        server-addr: localhost:8848
        file-extension: yml
        namespace: dev

步骤 3：迁移配置内容到 Nacos 控制台

1. 登录 Nacos 控制台，创建命名空间 dev（对应 Config 的 dev 环境）。
2. 创建配置：Data ID = user-service-dev.yml，Group = DEFAULT_GROUP。
3. 将 Git 仓库中 user-dev.yml 的配置内容复制到 Nacos 配置中，保存并发布。

步骤 4：验证迁移效果

1. 启动微服务，检查是否能正常拉取 Nacos 配置。
2. 修改 Nacos 中的配置并发布，调用接口验证配置是否动态刷新。
3. 验证通过后，下线 Config Server 服务。

4.2 从 Spring Cloud Config 切换到 Apollo

Apollo 的迁移需要注意配置格式的兼容性。

步骤 1：引入 Apollo 依赖，移除 Config 依赖

<!-- 移除 Config 依赖 -->
<!-- <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-config</artifactId> </dependency> -->
<!-- 引入 Apollo 依赖 -->
<dependency>
    <groupId>com.ctrip.framework.apollo</groupId>
    <artifactId>apollo-client</artifactId>
    <version>2.0.0</version>
</dependency>

步骤 2：修改配置文件

app:
  id: user-service
apollo:
  meta: http://localhost:8080
  bootstrap:
    enabled: true
    namespaces: application,user-service.common
  environment: dev

步骤 3：迁移配置内容到 Apollo 控制台

1. 登录 Apollo Portal，创建应用 user-service。
2. 在 dev 环境下，创建命名空间 application 和 user-service.common。
3. 将 Git 仓库中的配置内容复制到对应命名空间，注意 Apollo 支持 Properties 和 YAML 格式。

步骤 4：验证迁移效果

1. 启动微服务，检查配置是否加载成功。
2. 修改 Apollo 配置并发布，验证配置是否实时生效。
3. 下线 Config Server 服务，完成迁移。

迁移避坑指南

1. 配置优先级问题：Nacos/Apollo 的配置优先级高于本地配置，需注意冲突。
2. 动态刷新注解：Apollo 无需 @RefreshScope，Nacos 需要保留该注解。
3. 多环境隔离：迁移时需确保环境对应关系（Config 的 profile → Nacos 的 namespace/Apollo 的 environment）。

5. 选型建议

配置中心的选型没有最优解，只有最适合，需结合业务规模、团队能力和功能需求综合判断：

6. 总结与展望

配置中心是微服务架构的核心基础设施，三款主流方案各有优劣：

• Spring Cloud Config 胜在原生、极简，适合小型项目；
• Apollo 胜在企业级特性完备，适合大型企业；
• Nacos 胜在一体化、易用性高，是中小型微服务项目的首选。

未来，配置中心的发展趋势将是智能化、云原生：支持 AI 辅助配置优化、与 K8s 等云原生平台深度整合、提供更精细化的配置治理能力。

最后，选型的核心原则是贴合业务需求，不要盲目追求'高大上'的功能，适合自己的才是最好的！