From Monolith to Cloud‑Native: Evolution of Software Architecture

Architecture Evolution

Software development architecture can be divided into three stages: early, growth, and stable periods.

Early Stage – Monolithic Architecture

The first stage uses a simple server‑plus‑database model with a three‑layer MVC structure. It suits early enterprises with simple business, single‑function products, and frequent adjustments based on operational data. The focus is on modular separation to handle uncertain business changes.

Growth Stage – Scaling Architecture

When daily active users reach hundreds of thousands, the system must ensure stable operation while supporting rapid product iteration. Key practices include front‑end acceleration via CDN, horizontal scaling with load balancers, and database optimization (structured and unstructured data design, caching).

Typical technology choices: SpringMVC for the front‑end, SpringBoot + Vue for front‑back separation, MySQL for storage, Redis for cache, and Nginx for static resource hosting. Cache design follows a hit‑miss‑update flow, and high availability is achieved by deploying multiple nodes.

Stable Stage – Fully Distributed Architecture

In the stable period, both front‑end and data face high pressure, demanding high‑efficiency response, elastic scaling, and service‑oriented design such as microservices.

Application Architecture Overview

Cloud‑native architecture emphasizes non‑functional requirements like fault isolation, resilience, and automatic recovery, enabling elastic resources, cross‑data‑center high availability, and ultra‑high data availability (up to 99.9999999%).

Cloud‑Native Architecture Concept

Agile infrastructure provides on‑demand compute and storage via APIs, supporting developers, operators, and business users to provision and release resources programmatically.

Continuous delivery automates business requirement changes, iteration, and deployment.

Continuous Delivery Architecture and Process

DevOps integrates development and operations, fostering communication, collaboration, and automation throughout the lifecycle.

Microservices adopt a single‑responsibility philosophy, allowing independent expansion, upgrade, and deployment.

Architecture Design

Design includes business splitting, microservice design, a unified configuration center, and distributed tasks with consistency considerations.

Business Splitting

Principles: high cohesion, low coupling. Split by clear business boundaries, often based on data independence. Each business may use separate databases and codebases, with communication via synchronous (RESTful) or asynchronous (message queues) methods.

Microservice Design

Key aspects: service discovery, governance, framework selection, orchestration, and testing.

Service discovery dynamically tracks service address changes, using server‑side mechanisms (DNS, VIP load balancers) or client‑side registries (ZooKeeper, Consul).

Service governance covers the entire lifecycle, including elastic scaling (e.g., Kubernetes Horizontal Pod Autoscaler) and circuit‑breaker mechanisms to prevent cascading failures.

Microservice frameworks include Spring Cloud (based on Spring Boot) and Dubbo; Spring Cloud provides distributed configuration, service registration, routing, load balancing, and fault tolerance, while Dubbo suits large‑scale, long‑connection, small‑payload scenarios.

Service orchestration combines services for elastic scaling, gray releases, rolling upgrades, and resource configuration, often using container orchestration platforms like Docker and Kubernetes.

Testing encompasses unit, interface, integration, and system tests, with mock techniques to simulate dependent services.

Unified Configuration Center

The configuration center centralizes settings such as database connections, cache parameters, queue configurations, and runtime thresholds, simplifying configuration changes across services.

Distributed Scheduling and Locks

Distributed scheduled tasks must be highly available, elastically scalable, and centrally managed. Two models exist:

Preemptive scheduling : each worker competes for tasks from the scheduler, suitable for horizontal scaling but may cause excessive parallel polling.

Allocative scheduling : a single master node assigns tasks to workers, providing better load control but requiring a distributed lock (e.g., ZooKeeper or Redis) for master election.

Open‑source frameworks include Quartz, Chronos, and Kubernetes Scheduled Jobs. Quartz is widely used and supports clustering via pessimistic locks; Chronos offers leader election and web UI; Kubernetes native jobs manage events within the cluster.