Evolution of Large‑Scale Website Architecture: From Single‑Machine Deployment to Service‑Oriented Systems

Architecture Evolution

Large websites are characterized by massive data volumes and extremely high traffic; examples such as Baidu, Taobao, and JD are built as distributed systems that evolve over long periods.

1. Single‑Machine System

In the early stage, a single application server (e.g., Tomcat) hosts all resources packaged into a WAR file, including class files, dependent JARs, static assets (JS, CSS, images), and uploaded files stored in a server directory.

Features:

Browser directly interacts with the Java application (Tomcat).

Java accesses a local MySQL database via JDBC.

File I/O is performed directly by the Java process.

Performance and security concerns arise because Tomcat handles many concurrent connections poorly and is not optimized for static content.

1.2 Advanced Single‑Machine Deployment

Adding Nginx in front of Tomcat separates static and dynamic handling: browsers talk to Nginx, which forwards dynamic requests to Tomcat and serves static files directly from the file system.

2. Static‑Dynamic Separation Deployment

Static requests are routed to a dedicated static‑resource server (or cloud storage such as Alibaba OSS) while dynamic requests continue to be processed by the Java application behind Nginx. CDN accelerates static content delivery, eliminating the static‑resource bottleneck.

3. Application Clustering

To avoid a single‑server bottleneck, the system is split into multiple clusters:

Web cluster (Nginx instances)

Application cluster (multiple Java servers)

Database cluster

Web and application clusters communicate via HTTP; application servers talk to the database via JDBC. Session management becomes a challenge.

3.1 DNS Round‑Robin

Multiple A records are configured for the domain, allowing DNS to distribute client requests across several Nginx nodes.

3.2 Load Balancer (Nginx Reverse Proxy)

Nginx selects a backend application server based on configured load‑balancing algorithms and forwards the request.

3.3 Session Issues

Various strategies are discussed:

Session Sticky : Nginx pins a user to the same backend server (simple but stateful).

Session Replication : Sessions are synchronized across all Java instances (adds network and memory overhead).

Centralized Session Store : Sessions are kept in a dedicated store accessed by all servers.

Cookie‑Based Session : Session data is encoded in cookies (limited size, security concerns, bandwidth cost).

4. Database Read/Write Splitting

Master‑slave replication is introduced: writes go to the master, reads are distributed among multiple slaves, with asynchronous synchronization that may cause temporary data inconsistency.

5. Introducing Search and Cache

Search clusters (e.g., Elasticsearch) handle LIKE‑style queries, while cache clusters (e.g., Redis) accelerate hot‑data access.

6. Database Sharding

Two approaches are described:

Vertical Splitting : Different business data reside in separate database instances.

Horizontal Splitting : A single table is partitioned across multiple databases.

7. Application Vertical Splitting

The monolithic application is broken into multiple sub‑applications or sub‑sites, each deployed independently, reducing maintenance complexity but introducing code duplication challenges.

8. Service‑Oriented Architecture

Common business functions are packaged as independent services forming a service cluster. Front‑end subsystems become thin orchestrators that invoke these services via HTTP, Dubbo, Thrift, etc.

9. Introducing Message Queues

For asynchronous communication, a message middleware (e.g., RabbitMQ, Kafka) is added between services, enabling reliable decoupled processing.

10. Summary

Building a large system is a gradual process; architecture should be chosen based on business needs, data volume, and traffic patterns. Simpler designs are preferable as long as they fit the requirements.