Nacos 和 Apollo哪个更好用配置管理这个看似不起眼的环节一旦出现问题轻则功能异常重则全站崩溃。正因如此配置中心成为了微服务架构中的标配。而说到配置中心目前国内最热门的两个选择非Nacos和Apollo莫属。很多团队在选型时都会纠结到底哪个更好用今天这篇文章就专门跟大家聊聊这个话题希望对你会有所帮助。01 设计理念在深入技术细节之前我们先看看这两个框架的“出身”和设计理念这决定了它们的气质和边界。NacosNaming and Configuration Service是阿里巴巴2018年开源的项目它的野心从一开始就不只是配置中心——它想成为微服务的“一站式”基础设施同时提供服务发现和配置管理两大核心功能。这意味着如果你用了Nacos你可能就无需再引入Eureka或Consul了。它的口号是“一个更易于构建云原生应用的动态服务发现、配置和管理平台”。Apollo阿波罗则来自携程2016年开源。它从一开始就只专注做配置管理这一件事并在这个领域深耕细作。携程作为一家大型在线旅游平台内部有着极其复杂的配置治理需求多环境、多集群、权限控制、灰度发布等Apollo正是为了解决这些企业级痛点而生的。一个简单的比喻Nacos像一个功能丰富的“瑞士军刀”既能切菜配置又能开瓶服务发现Apollo则像一把顶级的“德国双立人厨师刀”它只切菜但在这个领域做到了极致。02 谁更容易上手对于“好不好用”最直观的感受就是上手成本。我们先分别跑一个简单的Demo看看两者的启动和集成难度。Nacos极简启动# 下载最新版Nacos Server wget https://github.com/alibaba/nacos/releases/download/2.2.3/nacos-server-2.2.3.zip unzip nacos-server-2.2.3.zip cd nacos/bin # 单机模式启动Linux/Mac sh startup.sh -m standalone # Windows startup.cmd -m standalone启动成功后访问http://localhost:8848/nacos默认用户名密码都是nacos。然后创建一个Spring Boot项目引入依赖dependency groupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-starter-alibaba-nacos-config/artifactId version2021.0.5.0/version /dependency dependency groupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-starter-alibaba-nacos-discovery/artifactId version2021.0.5.0/version /dependency在bootstrap.properties中配置spring.application.namemy-service spring.cloud.nacos.config.server-addr127.0.0.1:8848 spring.cloud.nacos.config.file-extensionproperties spring.cloud.nacos.discovery.server-addr127.0.0.1:8848然后就可以在代码中使用了RestController RefreshScope // 配置自动刷新注解 public class DemoController { Value(${user.name:default}) private String userName; GetMapping(/config) public String getConfig() { return Current user name: userName; } // 服务发现客户端注入 Autowired private DiscoveryClient discoveryClient; GetMapping(/services) public ListString services() { return discoveryClient.getServices(); } }从下载到跑通第一个配置读取熟练的话不超过10分钟。Nacos的一体化设计让配置和发现共用同一个服务端客户端配置也非常简洁。Apollo稍显复杂的部署Apollo的部署稍微复杂一些因为它本身就是一套分布式系统。它包含四个核心组件ConfigService提供配置读取和推送接口AdminService提供配置管理接口PortalWeb管理界面MetaServer服务发现实际上是Eureka官方提供了Quick Start脚本但依然需要几步操作# 下载Quick Start包 wget https://github.com/apolloconfig/apollo-quick-start/releases/download/v2.1.0/apollo-quick-start-2.1.0.zip unzip apollo-quick-start-2.1.0.zip cd apollo-quick-start # 执行脚本会自动启动MySQL和所有服务 ./demo.sh start启动成功后访问http://localhost:8070默认用户名/密码apollo/admin。Spring Boot集成dependency groupIdcom.ctrip.framework.apollo/groupId artifactIdapollo-client/artifactId version2.1.0/version /dependency在application.properties中配置app.idmy-service apollo.metahttp://localhost:8080 apollo.bootstrap.enabledtrue apollo.bootstrap.namespacesapplication代码中使用Component public class ApolloConfigBean { // 使用Value注解需要添加EnableApolloConfig注解 Value(${user.name:default}) private String userName; // 也可以直接使用API获取 public String getConfig(String key) { Config config ConfigService.getAppConfig(); return config.getProperty(key, default); } // 监听配置变化 ApolloConfigChangeListener private void onChange(ConfigChangeEvent changeEvent) { for (String key : changeEvent.changedKeys()) { System.out.println(key changed!); } } }小结在“开箱即用”这个维度上Nacos完胜。它的单机模式启动简单客户端配置也少。Apollo的Quick Start虽然也提供了脚本但因为组件多启动稍慢而且会占用更多端口。对于只想快速尝鲜的开发者来说Nacos更友好。03 核心功能“好用”不只是启动快更重要的是在复杂场景下能不能解决问题。我们逐一对比关键功能点。3.1 配置管理基础能力配置格式支持两者都支持properties、yaml、xml、json等常见格式。Nacos的控制台支持直接编辑yaml并提供了语法高亮Apollo也支持文本编辑但默认按key-value展示对于yaml来说体验稍差。版本管理两者都支持配置的历史版本和回滚。Apollo的版本管理粒度更细可以精确到每次发布并支持对比、查看变更详情。Nacos也有版本管理但相对简单。环境与集群管理Apollo天生支持多环境DEV、FAT、UAT、PRO和多集群数据中心每个环境的配置完全隔离这对于企业级应用非常友好。Nacos通过命名空间Namespace和分组Group来实现隔离理论上可以模拟出环境但需要自己规划命名策略没有Apollo那么直观。举个例子在Apollo中创建一个DEV环境的配置和一个PRO环境的配置完全是两个独立的配置项互不影响。而在Nacos中你可能需要在不同的Namespace中分别创建。3.2 配置推送的实时性Nacos的长轮询Long Polling机制Nacos采用HTTP长轮询实现配置推送。我来带你看看源码级别的实现// Nacos客户端发起长轮询的核心逻辑 public void start() { executor.scheduleWithFixedDelay(new LongPollingRunnable(), 0, retryInterval, TimeUnit.SECONDS); } class LongPollingRunnable implements Runnable { Override public void run() { // 构造订阅串包含当前配置的md5值 String listeningConfigs buildListeningConfigs(); Request request new Request.Builder() .url(serverAddr /v1/cs/configs/listener) .post(body) .build(); // 这里会阻塞最多30秒 try (Response resp httpClient.newCall(request).execute()) { if (resp.isSuccessful()) { String content resp.body().string(); // 如果有变更立即拉取最新配置 if (StringUtils.isNotEmpty(content)) { pullNewConfig(content); } } } } }服务端的处理更精妙客户端请求到达后服务端先比较md5如果有变更立即返回如果没有变更使用Servlet 3.0的AsyncContext挂起请求默认29.5秒同时启动一个定时任务超时后返回空响应如果期间配置变更触发LocalDataChangeEvent事件从挂起队列中找出相关客户端立即返回// 服务端挂起请求的核心代码 AsyncContext asyncContext request.startAsync(); asyncContext.setTimeout(0); // 禁用容器默认超时 ClientSubscription sub new ClientSubscription(keys, asyncContext); // 加到订阅列表 subscribers.computeIfAbsent(key, k - new CopyOnWriteArrayList()).add(sub); // 定时29.5秒后超时返回 ScheduledFuture? timeoutTask scheduler.schedule(() - { asyncContext.getResponse().getWriter().write(); asyncContext.complete(); }, 29500, TimeUnit.MILLISECONDS);这种设计的精妙之处在于既实现了准实时推送秒级又避免了WebSocket长连接的资源消耗同时兼容所有HTTP中间件。Apollo的定时轮询机制Apollo客户端默认每60秒拉取一次最新配置。虽然可以通过apollo.refreshInterval调整但本质上还是轮询。源码层面Apollo使用Spring的DeferredResult实现异步化// Apollo服务端关键类NotificationControllerV2 // 使用DeferredResult实现异步响应 RequestMapping(method RequestMethod.GET) public DeferredResultResponseEntityListApolloConfigNotification pollNotification( RequestParam(value appId) String appId, RequestParam(value cluster) String cluster, RequestParam(value notifications) String notificationsAsString, RequestParam(value dataCenter, required false) String dataCenter, RequestParam(value ip, required false) String clientIp) { DeferredResultResponseEntityListApolloConfigNotification deferredResult new DeferredResult(timeout); // 将deferredResult存入队列等待配置变更时唤醒 deferredResults.add(deferredResult); return deferredResult; }两种机制的对比维度Nacos长轮询Apollo定时轮询推送延迟秒级1-2秒依赖轮询间隔默认60秒服务端压力中等需维护挂起队列较低无状态连接数与客户端数量正相关与轮询频率相关穿透性好纯HTTP好纯HTTP如果业务对配置变更实时性要求高如秒杀开关、黑白名单Nacos的长轮询更有优势如果能接受分钟级延迟Apollo也能满足大多数场景。3.3 灰度发布与权限控制这是Apollo的绝对强项也是很多大厂选择它的核心原因。Apollo的灰度发布支持按IP、按机器、按用户标签进行配置的灰度发布。你可以先发布给一台机器验证没问题再逐步推送到全量。同时支持配置的全量回滚和灰度回滚操作界面非常友好。Apollo的权限控制提供应用级、环境级、命名空间级的多维度权限管理。你可以指定某个用户只能修改DEV环境的配置不能碰PRO或者只允许运维人员执行发布操作。所有的操作都有审计日志谁在什么时间改了哪个配置一目了然。相比之下Nacos的权限控制比较基础虽然也支持RBAC但粒度较粗。灰度发布需要自己通过多Namespace或多Group模拟或者结合配置中心的元数据功能手动实现对于大多数团队来说门槛较高。3.4 服务发现功能这是Nacos的独有优势Apollo完全不支持服务发现。Nacos的服务发现功能非常强大支持健康检查、临时/持久实例、权重路由、监听查询等完全可以替代Eureka或Consul。如果你的项目既需要配置中心又需要服务发现使用Nacos可以少维护一套系统架构更简洁。// Nacos服务发现客户端使用示例 RestController public class ConsumerController { Autowired private LoadBalancerClient loadBalancerClient; Autowired private RestTemplate restTemplate; GetMapping(/call) public String call() { // 从Nacos获取服务实例 ServiceInstance instance loadBalancerClient.choose(provider-service); String url http:// instance.getHost() : instance.getPort() /hello; return restTemplate.getForObject(url, String.class); } }如果选择Apollo你需要额外引入一套服务发现组件比如Eureka、Nacos Discovery或Consul增加了系统的复杂度。04 数据模型对比很多小伙伴在工作中分不清两者的数据模型特别是“Namespace”这个概念两者含义完全不同。4.1 Nacos的三层模型Nacos采用Namespace Group DataId三层结构Namespace代表环境隔离如dev、test、prod。客户端通过指定Namespace来访问不同环境的配置。Group代表逻辑分组如DEFAULT_GROUP、DATABASE_GROUP。DataId代表具体的配置文件通常格式为${serviceName}.properties。# Nacos配置示例 spring.cloud.nacos.config.namespacedev # 开发环境 spring.cloud.nacos.config.groupDEFAULT_GROUP # 默认分组 spring.cloud.nacos.config.dataIdorder-service.properties这种模型的好处是结构清晰与Kubernetes的命名空间概念类似理解成本低。但坏处是如果你需要管理多个环境必须在每个环境部署不同的Nacos集群或者通过权限隔离来控制访问。4.2 Apollo的四层模型Apollo的数据模型更复杂Environment AppId Cluster Namespace。Environment环境如DEV、FAT、UAT、PRO。AppId应用唯一标识。Cluster集群可用于区分数据中心或逻辑分组。Namespace在这里Namespace是配置文件的概念分为私有private和公共public两种。# Apollo配置示例 app.idorder-service apollo.metahttp://config-server:8080 apollo.bootstrap.namespacesapplication,TEST1.public apollo.clusterdefaultApollo的模型粒度更细天然支持多环境、多集群适合复杂的企业部署架构。但缺点也很明显——配置项过多初次上手容易迷失。05 架构对比我们用两张图来直观对比两者的架构。5.1 Nacos架构Nacos集群中各节点是对等的通过共享存储MySQL来保证数据一致性。客户端可以配置多个服务端地址或者通过负载均衡器接入。架构相对简单。5.2 Apollo架构Apollo的架构组件较多职责分离清晰ConfigService负责配置的读取和推送AdminService负责配置的修改和发布PortalWeb管理界面MetaServer基于Eureka的服务发现帮助客户端找到ConfigService这种架构的优点是每个组件都可以独立扩展比如ConfigService可以水平扩展而AdminService可以单独隔离。缺点是部署和维护成本高需要同时管理多个组件和数据库。06 性能与扩展性在性能方面两者都能满足绝大多数场景。我们曾做过压测单台Nacos Server在8核16G配置下可以稳定支撑5000客户端的长轮询连接。Apollo的ConfigService也是无状态的扩展性很好。但Apollo的一个潜在瓶颈是数据库。因为所有的配置拉取都会查询数据库虽然有缓存当客户端数量非常大时数据库压力会上升。Nacos同样依赖数据库但它在服务端有一层缓存可以减少数据库查询。在数据一致性方面两者都依赖于数据库事务保证了配置发布的原子性。07 运维成本与社区生态部署运维Nacos明显更简单。单机模式一条命令集群模式也只需要配置数据库和几个节点。Apollo最少需要启动三个组件ConfigService、AdminService、Portal且需要两个数据库ConfigDB和PortalDB对运维人员的要求更高。监控告警Nacos自带了简易的监控页面可以查看集群状态、健康检查等。Apollo也有监控但需要整合到企业监控系统。社区生态Nacos背靠阿里云社区非常活跃几乎每个月都有新版本GitHub Star已超过27k。文档齐全有中文社区。与Spring Cloud Alibaba、Dubbo等框架集成良好。Apollo携程开源社区也很成熟Star数约28k但发布频率相对较低约半年一个大版本。文档详细有企业微信交流群。08 如何选择结合以上对比我给出一些选型建议推荐选择 Nacos 的场景新项目技术栈为Spring Cloud Alibaba天然集成配置发现一体开发效率高。中小团队运维人力有限部署简单维护成本低。需要服务发现功能用Nacos可以省掉一套Eureka或Consul。对配置变更实时性要求较高长轮询机制秒级生效。推荐选择 Apollo 的场景大型企业有复杂的配置治理需求多环境、多集群、严格的权限控制和灰度发布。配置中心需要与现有CMDB、监控系统深度集成Apollo的开放API和丰富事件机制更适合。对配置变更的安全性要求极高金融、政务完整的审计日志和细粒度权限控制。团队已经有一套成熟的服务发现方案如自研或Consul只需要配置中心。折中方案也有一些团队采用混合架构服务发现用Nacos因为它轻量配置管理用Apollo因为它专业。这种方案虽然增加了组件但可以发挥各自优势适合大型项目。09 如何实现配置动态刷新最后给出一个示例展示在两种框架下如何实现配置的动态刷新。Nacos 动态刷新RestController RefreshScope public class NacosConfigController { Value(${my.config:default}) private String myConfig; GetMapping(/nacos/config) public String getConfig() { return Current config: myConfig; } }在Nacos控制台修改配置后无需重启调用接口就会看到新值RefreshScope是关键。Apollo 动态刷新RestController RefreshScope public class ApolloConfigController { Value(${my.config:default}) private String myConfig; GetMapping(/apollo/config) public String getConfig() { return Current config: myConfig; } }看起来几乎一样但需要注意两点需要EnableApolloConfig注解通常在启动类或配置类上加。Apollo默认的刷新时机是60秒轮询如果希望立即生效可以调用ConfigService的API强制刷新或集成消息总线。