Why Your Microservices Need a Distributed Configuration Center (and How to Build One)

1. Introduction

Configuration files let us modify program behavior at runtime. As the quote says, they enable dynamic adjustment of a system’s flight posture.

System runtime flight posture dynamic adjustment!

Just like repairing parts on a fast‑moving aircraft, we need control knobs to adjust direction, throttling, or gray‑scale releases, especially in the fast‑changing Internet industry.

For a single‑machine application we use a configuration file; for a distributed cluster we need a configuration center.

2. Why a Distributed Configuration Center Is Needed

Project background : The project uses SSM and an application.properties file loaded into memory at startup.

Requirement 1 : A username default "Xiao Qiang" must be changed to "Xiao Ming" without restarting during peak traffic. Modifying the file on each server at night is cumbersome and error‑prone.

Requirement 2 : Different environments (development, testing, production) need separate configurations, such as distinct databases. Manually switching files per environment is inefficient and breaks automated Jenkins‑Git‑Maven pipelines.

3. Evolution of Configuration

1. Single‑machine configuration file

2. Multi‑machine configuration

When traffic grows, a single service can no longer meet demand, leading to a micro‑service (SOA) architecture.

3. Distributed cluster configuration

This approach becomes a nightmare for rapid dynamic adjustments, highlighting the need for a unified configuration center.

4. A Simple Configuration Center Design

Features

CRUD of configuration items

Environment isolation (dev, test, pre‑release, gray/online)

High performance and high availability

Supports high request volume and concurrency

Read‑heavy, write‑light workload

Design

Use an OA system to manage each configuration item (unique ID) with CRUD operations.

Separate environment configurations by storing different records for the same ID.

Store configuration as JSON in a MySQL database for easy editing.

Introduce a Redis cluster as a cache (e.g., 1‑minute delay before changes take effect).

Deploy the configuration service on multiple machines to meet performance needs.

Optionally add historical modification records.

This design satisfies basic needs for configuration CRUD while tolerating short periods of data inconsistency.

Because every request still incurs an RPC call, a local cache (e.g., Ehcache) can be added on the client side.

5. Improvements on the Simple Design

Performance & availability : Introduce a client‑side local cache and asynchronous threads to update it, reducing RPC calls.

This achieves AP consistency (per the CAP theorem) with temporary inconsistency that eventually converges.

Data consistency : After a configuration change, notify services to clear both local and distributed caches, using MQ or ZooKeeper.

The final solution combines push and pull mechanisms to ensure eventual consistency.

6. Open‑Source Projects

Apollo : Ctrip’s distributed configuration center with real‑time push, permission control, and workflow governance.

Project: https://github.com/ctripcorp/apollo

XDiamond : A global configuration center derived from Alibaba’s Diamond project.

Project: https://github.com/hengyunabc/xdiamond

QConf : Distributed configuration management tool that separates config from code and provides real‑time sync.

Project: https://github.com/Qihoo360/QConf

Disconf : General component/platform for distributed system configuration, used by many large internet companies.

Project: https://github.com/knightliao/disconf

Spring Cloud Config : Provides server and client support for external configuration in distributed systems.

Project: https://github.com/spring-cloud/spring-cloud-config

Key differences among these solutions are illustrated in the following diagram: