Application High Availability Service (AHAS) is a SaaS product that improves the high availability of applications. It consists of two independent functional modules: MSHA and traffic protection. The traffic protection feature has been migrated to the microservice governance service, Microservice Engine (MSE).
Multi-site high availability
Multi-Site High Availability (MSHA) is a disaster recovery solution that evolved from the architecture used for Alibaba's e-commerce services. MSHA decouples service recovery from fault recovery. It uses features such as flexible rule-based scheduling, cross-domain and cross-cloud management, and data protection to ensure rapid service recovery during failures. This helps you build a stable and disaster-resilient system for your enterprise.
Workflow
The MSHA architecture divides a service into three layers: an access layer, an application layer, and a data layer. The application layer can be further divided into functional domains, such as microservice invocation and messaging. Each layer contains corresponding active-active components. This structure allows MSHA to provide full-stack management for the entire active-active architecture.
Scenarios
Architecture
Disaster recovery capability
Scenarios
Active zone-redundancy
RPO: Uncontrollable for region-level failures. Seconds to minutes for data center-level failures.
RTO: Uncontrollable for region-level failures. Minutes to tens of minutes for data center-level failures.
NoteThe actual time depends on the data synchronization latency between the primary and secondary sites.
Suitable for limited budgets that do not require geo-disaster recovery.
Requires a short implementation period of 2 weeks or less.
Requires no modifications to your service code.
Data consistency is not a primary concern.
Active-active geo-redundancy for applications
RPO: Minutes.
RTO: Minutes to tens of minutes.
NoteThe actual time depends on the data synchronization latency between the primary and secondary sites.
You can establish an off-site data center for disaster recovery.
Requires utilization of resources in the secondary data center and active-active traffic.
Tolerates cross-region network latency.
Requires few or no modifications to your service code.
Data consistency is not a primary concern.
Unlike active geo-redundancy, this solution does not require traffic tagging or routing correction.
Active geo-redundancy
RPO: Minutes.
RTO: Minutes to tens of minutes.
NoteThe actual time depends on the data synchronization latency between the primary and secondary sites.
Suitable for sufficient budgets to build an active-active data center in a different geographic region.
Accommodates a long implementation period of 3 to 6 months.
Allows traffic routing based on specific dimensions and requires data partitioning.
Requires modifications to your services to support traffic tagging and middleware upgrades.
Eventual data consistency is acceptable.