Application disaster recovery
Application multi-active is an advanced disaster recovery (DR) architecture that deploys production systems across multiple data centers simultaneously, enabling minute-level failover with no user-visible disruption.
Application multi-active deploys a production system — mirroring some or all of the local production system — across multiple data centers — within the same city or across different regions — so that applications in all data centers serve traffic simultaneously. When a failure occurs, the system reroutes traffic within minutes, often without users noticing any disruption. Active zone-redundancy and active geo-redundancy (also known as Unitization) are the two primary implementations of application multi-active.
Advantages of application multi-active
Minute-level Recovery Time Objective (RTO): Recovery is fast. Alibaba's internal production systems recover in under 30 seconds on average; external customer systems recover within one minute.
Full resource utilization: All data centers carry live traffic, eliminating the idle resource waste typical of cold-standby architectures.
High switch success rate: Built on a mature multi-active framework and a visualization Operations and Maintenance (O&M) platform, the architecture delivers over 99.9% switch success across thousands of annual traffic switches within Alibaba.
Precise traffic control: End-to-end traffic isolation and fine-grained routing direct specific service traffic to the right data center, enabling global grayscale releases and critical traffic assurance.
Design standards for application multi-active
Application multi-active supports cross-region and cross-platform deployments. A compliant architecture must meet four design standards:
Business flow active (BFA): Ensure business service continuity through fine-grained allocation of production traffic based on business characteristics.
Local region active (LRA): Enable the system to switch all or part of an application when the primary data center fails, treating each application as the smallest switchable unit in a distributed system.
Ultra distance active (UDA): Maintain good access performance across long distances — for example, more than 300 km between data centers — and keep Recovery Point Objective (RPO) and RTO within minutes when the system enters a DR state.
Hybrid cloud active (HCA): Abstract DR details from business logic and provide a unified multi-active programming model compatible with public cloud, private cloud, managed private cloud, and edge computing nodes.
Typical architectures for application multi-active
Intra-city application multi-active
Active zone-redundancy distributes applications across multiple data centers in the same city, all serving traffic simultaneously. Because the physical distance between data centers is typically under 100 km, networks and services are interconnected across the data centers. A local failure in one data center can propagate across the entire system, making the blast radius difficult to contain. The main challenges are traffic routing and isolation between data centers.
When a data center fails, a data-center-level switch is possible. For finer control — when a specific application within a data center fails — an application-level switch is required.
This architecture deploys services into logical zones called "cells". Traffic within each cell prioritizes in-zone calls. Because cross-data-center response time (RT) is low within the same city, services across cells can share a single-cluster mode, which avoids the complexity of data consistency.
Active zone-redundancy requires minimal application code changes. Flexible traffic scheduling across cells enables fast service recovery, decoupling service recovery from physical fault recovery.
Application multi-active for active geo-redundancy
Intra-city DR setups cannot survive regional disasters. Banking industry standards require DR centers to be in a different seismic zone, river basin, and power grid from the production center — typically more than 300 km away.
Active geo-redundancy distributes applications across multiple data centers in different regions, all serving traffic simultaneously. The primary challenge is network latency over long distances. High latency makes single-cluster operation across regions impractical, while multi-cluster operation introduces data consistency complexity.
Alibaba's Unitization solution addresses the distance limitation. The core idea is to shard data so that top-down traffic routing directs reads and writes for specific data shards to a designated data center. This resolves data consistency while enabling both DR and horizontal scaling. Each horizontally scalable logical center is called a "unit".
Units come in two types: center units and normal units. Services fall into three categories:
Global services: Require strong consistency. Reads and writes go to the center unit.
Core services: Split by unitization. Reads and writes go to normal units.
Shared services: Global read services frequently used by core services. Writes go to the center unit; reads come from normal units.
There is only one center unit, which hosts global, core, and shared services. Normal units host core and shared services and can be scaled horizontally and replicated as needed.
Application multi-active for hybrid cloud
A hybrid cloud combines public cloud, private cloud, managed private cloud, and edge computing nodes to meet enterprise requirements across infrastructure, middleware, the full developer lifecycle, and application platforms. According to an IDC report, in 2021 only 14% of customers chose a public cloud exclusively, while 86% adopted a multicloud or hybrid cloud architecture.
Hybrid cloud application multi-active runs applications distributed across a hybrid cloud environment simultaneously. This architecture decouples service recovery from the underlying cloud infrastructure, providing a consistent experience for development, O&M, and business operations regardless of which cloud components are involved.
The primary challenges are cloud independence and heterogeneity. Two goals must be met:
Multicloud integration: Consolidate accounts, permissions, resources, and data from multiple clouds into a unified operations interface.
Data interoperability: Enable infrastructure and heterogeneous middleware systems across clouds to discover each other and synchronize data, making cross-cloud DR possible.
Achieving both goals requires multicloud adaptation through three core capabilities:
Cloud service interface adaptation: Plugin-based lower-level multicloud adaptation with a unified cloud service interface at the upper level.
Data model adaptation: Abstraction of cloud accounts, permissions, resources, and data to normalize differences across clouds.
Unified DR interface: Standardized DR definitions and interfaces for fast integration of heterogeneous clouds and technology stacks.
Technical solution for application multi-active
The technical solution spans three layers: the application layer, the data layer, and the cloud platform. Each layer's components implement the four design standards and together form a complete multi-active architecture.
Application layer — the primary path for service traffic, with three components:
Access gateway: The first hop for incoming service traffic. Identifies and distributes traffic for the multi-active application with two core capabilities: data center routing and application routing.
Microservices: The synchronous call path for traffic within and across data centers. Includes consumers, providers, and a service registry. Delivers three core capabilities: traffic routing, traffic protection, and fault isolation.
Messaging: The asynchronous invocation path for traffic within and across data centers. Uses message queues for load leveling. Includes producers, consumers, and brokers.
Data layer — covers data read/write operations, storage, and synchronization for business applications. Its three core capabilities are traffic routing, data consistency, and data synchronization.
Cloud platform — the foundation that supports business applications. Can be a single cloud, a single data center, a multicloud, or a hybrid cloud.
