Master Apollo Config Center: From Core Concepts to SpringBoot Integration

1. Basic Concepts

Because Apollo has many concepts, it is recommended to understand them before hands‑on usage.

1.1 Background

As application functionality becomes more complex, configuration needs increase (feature switches, parameters, server addresses, etc.). Traditional file‑based or database configurations can no longer meet real‑time, gray‑release, multi‑environment, and permission requirements, leading to the emergence of Apollo Config Center.

1.2 Introduction

Apollo (developed by Ctrip) is an open‑source configuration management center that centralizes configuration for different environments and clusters, pushes updates in real time, and provides standardized permission and workflow governance.

1.3 Features

Simple deployment

Gray release

Version management

Open platform API

Client configuration monitoring

Native Java and .Net clients

Hot‑update of configuration

Permission management, release audit, operation audit

Unified management of configurations across environments and clusters

1.4 Basic Model

The basic workflow is:

User modifies and publishes configuration in the config center.

The config center notifies Apollo clients of the update.

Clients pull the latest configuration, update local cache, and notify the application.

1.5 Apollo’s Four Dimensions

Apollo manages key‑value configurations in four dimensions:

application – identifies which application the configuration belongs to.

environment – DEV, FAT, UAT, PRO, etc.

cluster – groups instances (e.g., Beijing vs. Shanghai data centers).

namespace – groups different configuration files (e.g., database.yml, rpc.yml).

1.6 Local Cache

The Apollo client caches configuration files locally so that when the server is unavailable or the network is down, the application can still read the cached configuration.

Default cache paths:

Mac/Linux: /opt/data/{appId}/config-cache

Windows: C:\opt\data\{appId}\config-cache

Cached files follow the naming pattern:

{appId}+{cluster}+{namespace}.properties

1.7 Client Design

The client maintains a long‑polling HTTP connection to receive push updates instantly. It also periodically pulls configuration (default every 5 minutes) as a fallback; the server returns 304 when no changes occur.

1.8 Overall Design

Key components:

Config Service – provides configuration read and push functions for clients.

Admin Service – handles configuration modification and publishing for the portal.

Both services are stateless, register to Eureka, and are discovered via a Meta Server.

Clients obtain service lists from the Meta Server and communicate directly with Config Service.

2. Apollo Creation and Configuration

Login to Apollo (username: apollo, password: admin), create a project, modify department data directly in the database if needed, set application ID (e.g., apollo-test) and name (apollo-demo), then create a configuration parameter with key test and value 123456 and publish it.

3. Create Apollo Client

Build a SpringBoot project and add the Maven dependency for apollo-client (version 1.4.0). In application.yml configure Apollo parameters such as apollo.meta, apollo.cluster, apollo.bootstrap.enabled, apollo.bootstrap.namespaces, cache directory, and auto‑update settings.

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" ...>
  ...
  <dependency>
    <groupId>com.ctrip.framework.apollo</groupId>
    <artifactId>apollo-client</artifactId>
    <version>1.4.0</version>
  </dependency>
  ...
</project>

# application.yml
server:
  port: 8080
spring:
  application:
    name: apollo-demo
app:
  id: apollo-test
apollo:
  meta: http://192.168.2.11:30002   # DEV environment address
  cluster: default
  cacheDir: /opt/data/
  bootstrap:
    enabled: true
    namespaces: application
    eagerLoad:
      enabled: false
  autoUpdateInjectedSpringProperties: true

Create a test controller to read the configuration value:

@RestController
public class TestController {
    @Value("${test:默认值}")
    private String test;

    @GetMapping("/test")
    public String test() {
        return "test的值为:" + test;
    }
}

@SpringBootApplication
public class Application {
    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }
}

Run the application with JVM parameters, e.g., -Dapollo.configService=http://192.168.2.11:30002 -Denv=DEV.

4. Run Project Tests

Access http://localhost:8080/test to verify the value comes from Apollo (123456). Modify the value in Apollo, publish, and observe the change without restarting. Test rollback, offline scenario (incorrect config service URL), and cache behavior by deleting cached files.

5. Explore Cluster, Environment, and Namespace

Demonstrate switching environments (DEV vs. PRO) by changing env and apollo.meta. Show cluster‑specific values by setting apollo.cluster=beijing or shanghai. Illustrate namespace isolation by creating private namespaces dev-1 and dev-2 and configuring different values for the same key.

6. SpringBoot Application Deployment

Build a Docker image using a Dockerfile that copies the JAR, sets JAVA_OPTS (including timezone) and APP_OPTS for Apollo parameters, and defines the entry point.

FROM openjdk:8u222-jre-slim
VOLUME /tmp
ADD target/*.jar app.jar
RUN sh -c 'touch /app.jar'
ENV JAVA_OPTS="-XX:MaxRAMPercentage=80.0 -Duser.timezone=Asia/Shanghai"
ENV APP_OPTS=""
ENTRYPOINT ["sh", "-c", "java $JAVA_OPTS -Djava.security.egd=file:/dev/./urandom -jar /app.jar $APP_OPTS"]

Create a Kubernetes deployment YAML that defines a Service (NodePort) and a Deployment, injecting JAVA_OPTS and APP_OPTS as environment variables to configure Apollo at runtime.

apiVersion: v1
kind: Service
metadata:
  name: springboot-apollo
spec:
  type: NodePort
  ports:
    - name: server
      nodePort: 31080
      port: 8080
      targetPort: 8080
  selector:
    app: springboot-apollo
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: springboot-apollo
spec:
  replicas: 1
  selector:
    matchLabels:
      app: springboot-apollo
  template:
    metadata:
      labels:
        app: springboot-apollo
    spec:
      containers:
        - name: springboot-apollo
          image: mydlqclub/springboot-apollo:0.0.1
          env:
            - name: JAVA_OPTS
              value: "-Denv=DEV"
            - name: APP_OPTS
              value: "--app.id=apollo-demo --apollo.bootstrap.enabled=true --apollo.bootstrap.eagerLoad.enabled=false --apollo.cacheDir=/opt/data/ --apollo.cluster=default --apollo.bootstrap.namespaces=application --apollo.autoUpdateInjectedSpringProperties=true --apollo.meta=http://service-apollo-config-server-dev.mydlqcloud:8080"
          ports:
            - containerPort: 8080
          resources:
            limits:
              memory: 1000Mi
              cpu: 1000m
            requests:
              memory: 500Mi
              cpu: 500m

Deploy with kubectl apply -f springboot-apollo.yaml -n mydlqcloud and test the endpoint via the NodePort.