Comprehensive Guide to Using Ctrip’s Open‑Source Apollo Distributed Configuration Center

Apollo is Ctrip’s open‑source distributed configuration center that offers functionality comparable to Nacos, enabling centralized management of configuration across multiple environments, clusters, and namespaces with real‑time push, gray release, version control, and permission auditing.

The core model consists of three steps: a user modifies and publishes configuration in the Apollo portal; the configuration service notifies Apollo clients of the change; each client pulls the latest configuration, updates its local cache, and notifies the application.

Apollo supports four dimensions of configuration management: application (identified by app.id ), environment (FAT, UAT, DEV, PRO), cluster (e.g., beijing, shanghai), and namespace (public or private groups of keys).

Namespaces have two permission types—public (accessible by any application) and private (accessible only by the owning application). They also have three types: private, public, and associated (inheritance) namespaces.

Clients cache configuration files locally under /opt/data/{appId}/config-cache on Linux/macOS or C:\opt\data\{appId}\config-cache on Windows, using file names formatted as {appId}+{cluster}+{namespace}.properties , which allows applications to continue operating when the configuration service is unavailable.

The client maintains a long‑polling HTTP connection to the server for instant push notifications; if no change occurs within 60 seconds, the server returns HTTP 304. A fallback polling interval (default 5 minutes) can be overridden with apollo.refreshInterval . The server handles thousands of concurrent long‑polling connections using async servlets (Spring DeferredResult).

Overall system design includes Config Service (read/push), Admin Service (modify/publish), both stateless and registered with Eureka, a Meta Server that abstracts service discovery, and load‑balanced client access to service instances.

The article walks through creating an Apollo project, adding a configuration key test=123456 , publishing it, and then building a SpringBoot demo that includes the Maven dependency com.ctrip.framework.apollo:apollo-client:1.4.0 . The application.yml file configures app.id , apollo.meta , apollo.cluster , cache directory, and bootstrap settings.

Java code examples include a TestController that injects the test value with @Value("${test:默认值}") and a standard SpringBoot Application class.

Runtime JVM parameters such as -Dapollo.configService=http:// :30002 -Denv=DEV are required; when the configuration service is unreachable, the client falls back to the locally cached file, and if the cache is deleted the default value is used.

Further experiments demonstrate environment switching (DEV ↔ PRO), cluster selection (beijing vs. shanghai) via apollo.cluster , and namespace selection (dev‑1 vs. dev‑2) via apollo.bootstrap.namespaces , each affecting the returned configuration value.

For Kubernetes deployment, a Dockerfile is provided that sets JAVA_OPTS and APP_OPTS environment variables, builds the image, and a Kubernetes manifest defines a Service (NodePort) and Deployment. The manifest injects JAVA_OPTS (e.g., -Denv=DEV ) and APP_OPTS with all Apollo settings, allowing the pod to retrieve configuration from the Apollo service running in the same cluster.

After deploying to Kubernetes, accessing the service via the NodePort (e.g., http:// :31081/test ) returns the value stored in Apollo, confirming successful integration.