Apollo Config — Distributed Configuration Management Center

Introduction

Apollo is a configuration management center developed by Ctrip (Trip.com Group) for distributed systems. It centralizes application configuration across environments and clusters, enabling real-time config pushes without restarting services. Apollo is widely adopted in production by organizations running Java-based microservice architectures.

What Apollo Config Does

• Centralizes configuration for multiple applications, environments, and clusters in a single portal
• Pushes configuration changes to clients in real time (typically under 1 second)
• Tracks full version history of every configuration change with rollback support
• Supports gray releases to push config changes to specific instances before full rollout
• Provides namespace-based config isolation with inheritance and override capabilities

Architecture Overview

Apollo follows a three-tier architecture: the Config Service handles config reading and real-time push via long polling, the Admin Service manages config modifications through the Portal, and the Meta Server acts as a service discovery layer. Clients maintain a local cache for resilience against network failures. Eureka is embedded for internal service registration, and a MySQL database stores all configuration data, audit logs, and release history.

Self-Hosting & Configuration

• Requires Java 8+ runtime and MySQL 5.7+ for persistent storage
• Deploy Config Service, Admin Service, and Portal as separate processes for production
• Configure server.properties with database connection strings and Eureka endpoints
• Use environment variables or -D JVM flags to set per-environment Meta Server addresses
• Docker and Kubernetes Helm charts are available for containerized deployments

Key Features

• Multi-environment management (DEV, FAT, UAT, PRO) from a single dashboard
• Access control with per-namespace permissions and operation audit logging
• Open API for programmatic config management and CI/CD integration
• Client-side caching ensures applications continue running even if Apollo is temporarily unavailable
• Supports multiple config formats including properties, XML, JSON, YAML, and plain text

Comparison with Similar Tools

• Spring Cloud Config — Git-backed and simple but lacks a management UI, real-time push, and gray release capabilities
• Consul KV — Lightweight key-value store with watches, but no versioning, rollback, or structured namespace model
• etcd — Low-level distributed KV store best for infrastructure config rather than application-level settings
• Nacos — Combines service discovery and config with a similar feature set, but Apollo has a more mature permission and release workflow

FAQ

Q: Does Apollo support non-Java applications? A: Yes. Apollo provides an Open API and clients for Go, Python, Node.js, PHP, and .NET in addition to its native Java client.

Q: How does Apollo handle config changes during a deployment? A: Config changes are pushed in real time via long polling. Applications receive updates without restarting. For staged rollouts, use the gray release feature to target specific instances.

Q: Can Apollo run in Kubernetes? A: Yes. Official Helm charts are available, and the community maintains Kubernetes-native deployment guides with ConfigMap integration.

Q: What happens if the Apollo server goes down? A: Clients cache the last-known configuration locally. Applications continue operating with cached values until the server recovers.

Sources

• https://github.com/apolloconfig/apollo
• https://www.apolloconfig.com/