Evolution of Server‑Side Architecture: From Single‑Machine Deployment to Cloud‑Native Microservices

1. Overview

The article illustrates, with Taobao as an example, how a backend system evolves from handling a few hundred users on a single server to supporting millions of concurrent requests, and lists the technologies introduced at each evolutionary stage.

2. Basic Concepts

Distributed: Components run on different machines, e.g., separating Tomcat and the database.

High Availability: The system continues to serve requests when some nodes fail.

Cluster: Multiple servers work together as a single service.

Load Balancing: Requests are evenly distributed across nodes.

Forward/Reverse Proxy: Forward proxy accesses external networks on behalf of internal services; reverse proxy forwards external requests to internal servers.

3. Architecture Evolution

3.1 Single‑Machine Architecture

Tomcat and the database are deployed on the same server; as traffic grows, resource contention becomes a bottleneck.

3.2 First Evolution – Separate Tomcat and Database

Tomcat and the database are placed on different machines, improving performance but making database read/write a new bottleneck.

3.3 Second Evolution – Local and Distributed Caching

Introduce in‑process caches and external caches (Memcached, Redis) to intercept most read requests, reducing database load.

3.4 Third Evolution – Reverse Proxy Load Balancing

Deploy multiple Tomcat instances behind Nginx/HAProxy; requests are distributed, increasing concurrency capacity.

3.5 Fourth Evolution – Database Read/Write Separation

Split the database into read replicas and a write master, using middleware such as Mycat to synchronize data.

3.6 Fifth Evolution – Business‑Level Sharding

Store different business data in separate databases to reduce contention; high‑traffic businesses can be scaled independently.

3.7 Sixth Evolution – Large Table Splitting

Partition big tables (e.g., by product ID or hour) into many small tables; horizontal scaling is achieved via MPP databases like TiDB, Greenplum, etc.

3.8 Seventh Evolution – LVS/F5 Load Balancing

Use layer‑4 load balancers (LVS software or F5 hardware) to balance traffic among multiple Nginx instances, with keepalived for high availability.

3.9 Eighth Evolution – DNS Round‑Robin

Configure DNS to return multiple IPs for a domain, achieving inter‑datacenter load balancing.

3.10 Ninth Evolution – NoSQL and Search Engines

Introduce technologies such as HBase, Redis, Elasticsearch, Kylin, Druid, etc., to handle massive data, full‑text search, and analytical workloads.

3.11 Tenth Evolution – Split Large Applications

Divide a monolithic application into smaller, business‑oriented services, using Zookeeper for distributed configuration.

3.12 Eleventh Evolution – Extract Reusable Functions as Microservices

Common functionalities (user management, payment, authentication) become independent microservices, managed via Dubbo, Spring Cloud, etc.

3.13 Twelfth Evolution – Enterprise Service Bus (ESB)

Adopt an ESB to unify protocol conversion and hide interface differences, moving towards an SOA architecture.

3.14 Thirteenth Evolution – Containerization

Package services as Docker images and orchestrate them with Kubernetes, enabling dynamic scaling and environment isolation.

3.15 Fourteenth Evolution – Cloud Platform

Deploy the system on public cloud (IaaS/PaaS/SaaS), leveraging elastic resources, managed services, and pay‑as‑you‑go pricing.

4. Architecture Design Summary

The article concludes with design principles such as N+1 redundancy, rollback capability, feature toggles, monitoring, multi‑active data centers, mature technology adoption, resource isolation, horizontal scalability, purchasing non‑core components, using commercial hardware, rapid iteration, and stateless service design.