Nacos vs Apollo: Which Config Center Is Faster and Easier for Microservices?

Design Philosophy

Nacos (Alibaba, 2018) aims to be a one‑stop infrastructure for microservices, providing both service discovery and configuration management. Apollo (Ctrip, 2016) focuses solely on configuration management and offers enterprise‑grade features such as multi‑environment isolation, gray releases, and fine‑grained permission control.

Getting Started

Nacos – Minimal Setup

# Download and unzip Nacos Server 2.2.3
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
# Start in standalone mode (Linux/Mac)
sh startup.sh -m standalone
# Windows
startup.cmd -m standalone

Access http://localhost:8848/nacos (default user/password: nacos).

<dependency>
  <groupId>com.alibaba.cloud</groupId>
  <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
  <version>2021.0.5.0</version>
</dependency>

spring.application.name=my-service
spring.cloud.nacos.config.server-addr=127.0.0.1:8848
spring.cloud.nacos.config.file-extension=properties
spring.cloud.nacos.discovery.server-addr=127.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 List<String> services() {
        return discoveryClient.getServices();
    }
}

Apollo – Slightly More Complex Deployment

# Download Quick‑Start package
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
# Start MySQL and all services
./demo.sh start

Access http://localhost:8070 (default user/password: apollo/admin).

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

app.id=my-service
apollo.meta=http://localhost:8080
apollo.bootstrap.enabled=true
apollo.bootstrap.namespaces=application

@Component
public class ApolloConfigBean {
    @Value("${user.name:default}")
    private String userName;

    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!");
        }
    }
}

Core Feature Comparison

Configuration Basics

Supported Formats : Both support properties, YAML, XML, JSON.

Version Management : Both keep history and allow rollback; Apollo provides finer‑grained diff view.

Environment & Cluster Management : Apollo natively supports multiple environments (DEV, FAT, UAT, PRO) and clusters. Nacos uses Namespace and Group to simulate environments, requiring naming conventions.

Real‑Time Push

Nacos Long‑Polling Mechanism

Nacos uses HTTP long‑polling (up to 30 s). The client repeatedly sends a request; the server returns immediately on change or holds the request using AsyncContext until timeout.

public void start() {
    executor.scheduleWithFixedDelay(new LongPollingRunnable(), 0, retryInterval, TimeUnit.SECONDS);
}

class LongPollingRunnable implements Runnable {
    @Override
    public void run() {
        String listeningConfigs = buildListeningConfigs();
        Request request = new Request.Builder()
            .url(serverAddr + "/v1/cs/configs/listener")
            .post(body)
            .build();
        try (Response resp = httpClient.newCall(request).execute()) {
            if (resp.isSuccessful()) {
                String content = resp.body().string();
                if (StringUtils.isNotEmpty(content)) {
                    pullNewConfig(content);
                }
            }
        }
    }
}

Server side holds the request with AsyncContext, returns when a change occurs or after a 29.5 s timeout.

Apollo Timed Polling Mechanism

Apollo clients poll every 60 s by default (configurable via apollo.refreshInterval) using Spring’s DeferredResult for asynchronous responses.

@RequestMapping(method = RequestMethod.GET)
public DeferredResult<ResponseEntity<List<ApolloConfigNotification>>> pollNotification(...) {
    DeferredResult<ResponseEntity<List<ApolloConfigNotification>>> deferredResult = new DeferredResult<>(timeout);
    deferredResults.add(deferredResult);
    return deferredResult;
}

Result: Nacos achieves second‑level latency; Apollo’s default latency is around one minute.

Gray Release & Permission Control

Apollo excels at gray releases (IP, machine, user‑tag based) and provides fine‑grained permission management with full audit logs. Nacos offers basic RBAC but lacks built‑in gray‑release features.

Service Discovery

Nacos includes built‑in service discovery (health checks, weight routing, dynamic queries). Apollo does not provide discovery; an external solution such as Eureka, Consul, or Nacos Discovery must be added.

Data Model Comparison

Nacos Three‑Layer Model

Namespace : Environment isolation (dev, test, prod).

Group : Logical grouping (e.g., DEFAULT_GROUP).

DataId : Actual configuration file name (e.g., order-service.properties).

spring.cloud.nacos.config.namespace=dev
spring.cloud.nacos.config.group=DEFAULT_GROUP
spring.cloud.nacos.config.dataId=order-service.properties

Apollo Four‑Layer Model

Environment : DEV, FAT, UAT, PRO.

AppId : Unique application identifier.

Cluster : Data‑center or logical grouping.

Namespace : Configuration namespace (private or public).

app.id=order-service
apollo.meta=http://config-server:8080
apollo.bootstrap.namespaces=application,TEST1.public
apollo.cluster=default

Architecture Comparison

Nacos forms a peer‑to‑peer cluster backed by a shared MySQL store. Clients can list multiple server addresses or go through a load balancer.

Apollo consists of four components: ConfigService (read/push), AdminService (modify/publish), Portal (Web UI), and MetaServer (Eureka‑based discovery). This separation offers extensibility but increases deployment complexity.

Performance & Scalability

Nacos Server (8 CPU, 16 GB) can handle >5 000 concurrent long‑polling clients.

Apollo ConfigService is stateless and scales horizontally; however, heavy client loads can stress the underlying database.

Both ensure configuration consistency via database transactions.

Operational Cost & Community

Deployment : Nacos is a single binary for single‑node and straightforward clustering. Apollo requires at least three services and two databases.

Monitoring : Nacos provides a built‑in status page; Apollo needs integration with external monitoring tools.

Community : Nacos (Alibaba) has >27k GitHub stars, frequent releases, and strong Spring Cloud Alibaba integration. Apollo (Ctrip) has ~28k stars, mature but slower release cadence.

How to Choose

When Nacos Is Recommended

New projects using Spring Cloud Alibaba.

Small to medium teams with limited ops resources.

Need built‑in service discovery.

Require near‑real‑time config updates (second‑level latency).

When Apollo Is Recommended

Large enterprises with complex multi‑environment, multi‑cluster governance.

Strict security, audit, and gray‑release requirements.

Existing service‑discovery solution in place.

Need deep integration with CMDB or monitoring systems.

Hybrid Approach

Some teams run Nacos for service discovery and Apollo for advanced configuration management, leveraging the strengths of both.

Dynamic Configuration Refresh

Nacos

@RestController
@RefreshScope
public class NacosConfigController {
    @Value("${my.config:default}")
    private String myConfig;

    @GetMapping("/nacos/config")
    public String getConfig() {
        return "Current config: " + myConfig;
    }
}

The @RefreshScope annotation forces bean reloading when Nacos pushes a change.

Apollo

@RestController
@RefreshScope
public class ApolloConfigController {
    @Value("${my.config:default}")
    private String myConfig;

    @GetMapping("/apollo/config")
    public String getConfig() {
        return "Current config: " + myConfig;
    }
}

Enable Apollo client with @EnableApolloConfig on a configuration class. The default refresh interval is 60 s; immediate refresh can be triggered via ConfigService or a message bus.

Conclusion

Neither Nacos nor Apollo is universally better; each fits different scenarios. Choose Nacos for simplicity, built‑in service discovery, and fast push latency. Choose Apollo for enterprise‑grade governance, fine‑grained permissions, and sophisticated gray releases. Consider team size, future growth, and operational constraints when making the decision.