Apollo Configuration Center Practice and Architecture at YouZan

This article introduces Apollo, a distributed configuration center developed by Ctrip, and its practical implementation at YouZan.

Background: In the era of centralized development, configuration files were sufficient as systems were deployed on single machines. However, with distributed systems deployed across N machines, restarting each machine individually becomes a significant burden. Additionally, companies need multiple environments (testing, production) and different configurations for various clusters within the same environment. This necessitates a configuration center for centralized management.

Apollo Overview: Apollo is a distributed configuration center that centrally manages application configurations across different environments and clusters. It provides real-time configuration push to applications and includes features like permission management and process governance. The server is built on Spring Boot and Spring Cloud, packaged as a runnable JAR without requiring additional application containers like Tomcat.

YouZan Implementation - Deployment: YouZan uses four environments: DAILY, QA, PRE, and PROD. Apollo supports environment and cluster-level isolation, where environments require separate databases while clusters are logically isolated. Since RDS only supports three environments, YouZan created a PRE cluster within the PROD environment as a virtual PRE environment, though this approach introduced compatibility costs.

YouZan Implementation - Cloud Deployment: To support external developers on YouZan's SaaS cloud, Apollo needed security enhancements. The open-source version lacked proper security controls, allowing any application to access other applications' configurations by forging app names. The solution involved issuing credentials to applications and extending the Namespace model with a scope attribute to restrict access.

Architecture: Apollo consists of Config Service (provides configuration reading/pushing for clients), Admin Service (provides configuration modification/publishing for Portal), and Eureka for service registration. Meta Server encapsulates Eureka's service discovery, and clients access Config Service via Meta Server with load balancing and retry mechanisms.

Namespace Design: Namespaces are collections of configuration items. Three types exist: private (only accessible by the owning application), public (accessible by any application, globally unique names required), and associated (inherits from public Namespace to override specific configuration items).

Client Implementation: Clients poll Config Service using two mechanisms: RemoteConfigRepository for periodic polling via /configs/{appId}/{clusterName}/{namespace:.+} interface, and RemoteConfigLongPollService for long polling via /notifications/v2 interface to receive change notifications.

Future Improvements: 1) Replace HTTP long polling with WebSocket for better resource efficiency and real-time performance. 2) Unify static and dynamic configuration centers using Apollo. 3) Replace Eureka with ETCD for service registration to decouple from ConfigService and improve stability.