Evolution of Internet Architecture: From Single‑Server to Microservices

1. Introduction

The rapid transformation of internet architecture—from monolithic OA/CRM/ERP systems to modern distributed micro‑service platforms—has increased pressure on developers to keep up with constantly evolving technologies, requiring a macro‑level view to make strategic decisions.

This article explores the evolution of internet architecture, explains the technologies and applications at each stage, and helps readers position their current projects and plan future learning.

2. Architecture Evolution

In a previous article the author listed the business modules of large e‑commerce and P2P systems. The current article continues the discussion, focusing on how architecture and technology evolve alongside business growth.

01 Single‑Instance System

Typical for beginners, a simple Java project with a database connection deployed on a local Tomcat server.

02 Nginx Load Balancing + Server Cluster

When a personal blog gains massive traffic, a single server becomes insufficient. Adding one or more peer servers and using a load balancer (e.g., Nginx) distributes requests, improving capacity.

Question 1: How do the peer servers recognize incoming requests?

Load balancers such as Nginx handle request distribution; hardware balancers like F5 are used by wealthier companies.

Nginx provides three core functions:

1. Reverse Proxy – hides the actual backend servers from clients, similar to a call center routing calls.

2. Static/Dynamic Separation – serves static assets (js, html, images) from Nginx while dynamic content (jsp, java) is handled by Tomcat, reducing backend load.

3. Load Balancing – distributes requests across servers using balancing algorithms.

Question 2: How to ensure fair request distribution?

Common Nginx algorithms include:

1. Least Connections (LC) – selects the server with the fewest active connections.

2. Round‑Robin – cycles through servers evenly.

3. ip_hash – hashes the client IP to consistently route a client to the same server, preserving session affinity.

Question 3: How do servers return responses to users?

Typical cluster modes:

1. NAT Mode – clients access a virtual IP; Nginx rewrites the request to the real Tomcat IP and the response follows the same path.

2. Direct Routing (DR) Mode – responses bypass Nginx and go directly to the client, reducing latency.

Question 4: How to maintain session consistency across servers?

Solutions include:

1. ip_hash – fixes a client to a specific server.

2. Session Broadcast – replicates session data to all servers (resource‑intensive).

3. Session Persistence – stores sessions in a shared store such as Redis.

4. Client‑Side Storage – stores session data in cookies (limited size and security concerns).

03 HA High‑Availability + Load Balancing + Server Cluster

Introducing a second Nginx with HA (High Availability) prevents a single point of failure. HA is achieved using LVS (Linux Virtual Server) and Keepalived.

1. LVS – kernel‑level load balancer operating at layer 4, offering high performance and fault tolerance.

2. Keepalived – monitors server health via heartbeat packets and promotes a standby server when the primary fails.

04 CDN + Varnish Server Cluster

Content Delivery Networks (CDN) place static resources on edge servers close to users, reducing latency. Varnish, an HTTP accelerator and reverse proxy, sits in front of Nginx to further offload static content.

05 Database Read/Write Separation

Master‑slave replication separates write operations (master) from read operations (slaves), improving scalability for read‑heavy workloads.

06 NoSQL + Distributed Search Engine

Redis is introduced as an in‑memory NoSQL cache to alleviate MySQL pressure. Elasticsearch provides a distributed full‑text search engine for fast, scalable queries.

07 NoSQL HA + Sharding + MyCat

Redis clustering (e.g., Codis) ensures high availability. Database sharding (vertical and horizontal) splits large tables across multiple databases. MyCat middleware handles distributed transactions, routing, and cross‑database queries.

08 Distributed File System

Large binary files (images, videos) are stored using distributed file systems such as MogileFS or FastDFS, avoiding database bottlenecks.

09 Application Service Decomposition + Message Middleware

Business components are split into independent services. Service governance uses Zookeeper for registration, Dubbo for RPC, and message queues (ActiveMQ, RabbitMQ, Kafka, RocketMQ) for asynchronous communication.

10 Microservice Architecture

Microservices encapsulate single business capabilities, enabling independent development, deployment, and scaling. Frameworks like Spring Cloud provide service discovery, configuration, load balancing, circuit breaking, and monitoring.

3. Conclusion

The article provides a concise overview of each architectural stage, explaining why specific technologies appear, what problems they solve, and how they fit into the broader evolution of internet systems, encouraging developers to maintain a macro perspective on architecture trends.