Common High‑Availability Architecture Patterns and Multi‑Active Deployment Strategies

This article introduces the typical high‑availability (HA) techniques used in Internet services, such as service redundancy, asynchronous design, load balancing, rate limiting, circuit breaking, service governance, and distributed storage. It focuses on disaster‑recovery (DR) architectures that ensure service continuity across multiple data‑centers.

1. Same‑city multi‑center architecture – The most common form is a dual‑center or triple‑center deployment within the same city. Two data‑centers are connected by high‑speed fiber with latency < 2 ms. The distance between centers should be > 50 km to avoid a single power‑outage zone. The design treats the two sites as a logical data‑center, requiring multiple fiber links to prevent split‑brain scenarios. Adding a third center is rarely used because the cost increase is high while the HA gain is limited.

2. Cross‑city multi‑center architecture – Similar to the same‑city model but the centers are located in different cities. It supports city‑level disaster recovery, user partitioning (e.g., north‑south users routed to Beijing or Shenzhen), and active‑active deployment. Two variants exist: near‑city (inter‑city latency < 10 ms) and far‑city (latency > 30 ms). Near‑city setups can be treated as a logical data‑center, while far‑city setups require separate logical zones.

3. Cross‑country multi‑center architecture – Deploys data‑centers across continents. It addresses global compliance, regional user partitioning, and cannot provide active‑active due to latency and regulatory constraints. Examples include Google and Facebook’s global data‑center footprints.

4. Comparison of five architecture patterns – The article compares cold standby, dual‑active, same‑city active‑active, cross‑city active‑active, and cross‑region active‑active solutions, highlighting their trade‑offs in cost, latency, and fault‑tolerance.

5. Multi‑active deployment models – Three major models are described: • Business‑customized active‑active – Tailored per‑service solutions (e.g., e‑commerce vs. social media). • Business‑generic active‑active – Uses shared services (traffic scheduling, DR, DAL) to enable active‑active without per‑service redesign. • Storage‑generic active‑active – Relies on distributed consistent storage (e.g., OceanBase, etcd) to achieve active‑active with minimal application changes.

6. Key technical components – The article outlines essential building blocks: traffic scheduling (Spanner‑like gateway), LDC routing (entry, service, data layers), Data Replication Center (DRC) for real‑time sync, Database Access Layer (DAL) for proxying MySQL, configuration center, publishing platform, and message‑queue routing.

7. Design methodology – A systematic approach includes business prioritization, data classification (modification rate, consistency, uniqueness, loss tolerance, recoverability), data synchronization strategies, and exception handling (graceful degradation, compensation, manual repair).

8. Practical considerations – Discusses cache invalidation in active‑active environments, MQ routing to avoid double‑writes, and disaster‑recovery procedures such as traffic cut‑over, synchronization verification, and failover steps.

The article concludes with common HA metrics (RTO, RPO, WRT, MTD) and references for further reading.