How Multi-Active Architecture Can Eliminate Downtime: Inside Alibaba Cloud’s AppActive

Downtime and Recovery Metrics

Major cloud services experienced outages lasting from several hours to multiple days, demonstrating the business impact of downtime. Studies show that 96% of enterprises suffered at least one interruption in the past three years, with hourly losses ranging from $25,000 for small firms to $540,000 for large ones.

Recovery Time Objective (RTO) is the maximum acceptable time to restore services after a disaster. Recovery Point Objective (RPO) is the maximum tolerable data loss measured as a time interval.

Multi‑Active Architecture vs. Traditional Disaster Recovery

Traditional disaster‑recovery (DR) focuses on protecting data copies and often leaves the application and business layers uncertain during a failure, causing delayed cut‑over decisions. Multi‑active architecture treats the entire application as continuously active across multiple sites, enabling traffic to be switched within minutes without user impact.

Typical deployment scenarios:

Same‑city multi‑active (physical distance < 100 km)

Cross‑region multi‑active (physical distance > 300 km)

Hybrid‑cloud multi‑active (combining private IDC, public clouds, and heterogeneous platforms)

AppActive Open‑Source Project

AppActive is the first open‑source project that defines “application multi‑active”. The source code is hosted at https://github.com/alibaba/Appactive. The project is released at version v0.1 and provides standard interfaces for the application, data, and cloud‑platform layers, with reference implementations based on Nginx, Dubbo, and MySQL.

Three‑Layer Abstraction

Application Layer : Manages global traffic routing consistency via access gateways, micro‑services, and messaging components. The gateway performs Layer‑7 routing based on business attributes; services and message queues enforce routing correction, traffic protection, and fault isolation.

Data Layer : Guarantees data consistency, synchronization, and source switching to avoid dirty writes and to enable disaster recovery.

Cloud Platform Layer : Provides the underlying multi‑cloud foundation, integrating private IDC, public clouds, and heterogeneous environments to deliver PaaS‑level DR capabilities.

Roadmap

Short‑term plans (v0.1 → v0.2):

Enrich plugins for access, service, and data layers to support additional technologies.

Extend standards and implementations for message‑level multi‑active.

Build a control‑plane to improve operational completeness.

Adopt the LRA standard for same‑city multi‑active.

Adopt the HCA standard for hybrid‑cloud multi‑active.

Long‑term goal: mature AppActive into a de‑facto standard for production‑grade multi‑active, supporting distributed cloud scenarios across multiple providers, platforms, and geographic locations.

Related Open‑Source Tool

Alibaba also open‑sourced the chaos‑engineering tool ChaosBlade at https://github.com/chaosblade-io/chaosblade, which focuses on fault injection and complements AppActive’s defensive approach.