Understanding Cloud‑Native Architecture and Its Key Patterns

Alibaba defines cloud‑native architecture based on its own technologies, products, and cloud migration experience, offering a specific interpretation among many existing definitions.

From a technical viewpoint, cloud‑native architecture is a collection of architectural principles and design patterns built on cloud‑native technologies, aiming to strip non‑business code from applications so that the cloud infrastructure handles elasticity, resilience, security, observability, gray‑release, and other non‑functional features, resulting in lightweight, agile, highly automated systems.

Only business code delivers real value; as software size, module count, deployment environments, and distributed complexity grow, the difficulty of building software increases and places higher skill demands on developers.

Service‑Oriented Architecture is the standard pattern for cloud‑native applications, dividing software into modules with interface contracts (e.g., IDL) and standard protocols (HTTP, gRPC). It combines DDD, TDD, and containerized deployment, with microservices and mini‑service patterns to balance granularity and governance overhead.

Mesh Architecture separates middleware (RPC, caching, async messaging) from business processes, leaving a thin client that communicates with a mesh process handling flow control, security, and other concerns, enabling transparent middleware upgrades and migrations.

Serverless Mode removes deployment responsibilities from developers, letting the cloud start, schedule, and stop business processes on demand. It suits event‑driven, short‑lived, stateless workloads but is unsuitable for stateful, long‑running, or heavy I/O‑bound applications.

Storage‑Compute Separation recommends storing all transient, structured, and unstructured data in cloud services to achieve CAP‑friendly availability and partition tolerance, while using event logs and snapshots to mitigate performance penalties for large transactional state.

Distributed Transaction Patterns include XA (strong consistency, poor performance), BASE (high performance, limited applicability), TCC (application‑controlled, high cost), SAGA (compensating transactions), and SEATA AT (high performance with automatic rollback), each with trade‑offs.

Observability Architecture comprises logging, tracing, and metrics. Architects should adopt open‑source frameworks (e.g., OpenTracing, OpenTelemetry), define clear SLOs for latency, concurrency, availability, and capacity, and ensure sufficient context propagation for effective distributed tracing.

Event‑Driven Architecture (EDA) integrates applications via events with schemas and QoS guarantees. It enhances service resilience, enables CQRS, provides data‑change notifications, supports open interfaces, facilitates stream processing (e.g., Kafka), and fits IoT scenarios where massive sensor data is processed asynchronously.

The article references the "Cloud‑Native Technology Architecture White Paper" and provides links for downloading the full white paper and related e‑book bundles.