Evolution of Internet Technical Architecture: From Single‑Server to Distributed Microservices

The internet is constantly changing, and so is its architecture; architecture evolves alongside the internet itself, aiming to solve business and human problems through systematic design.

In the context of the internet industry, "architecture" usually refers to technical or system architecture, especially website architecture.

Single‑Machine Era

Early internet projects often packed all components—application, file service, database—onto a single server, forming a monolithic architecture (e.g., Java WAR, Rails directory). This simple, fast, and easy‑to‑test approach has clear advantages but suffers from single‑point failures and poor scalability.

To improve maintainability, a layered (MVC) architecture emerged, separating presentation, business, persistence, and database layers. Adding data separation further isolates application and data services, improving resource utilization.

As traffic grew, caching (local and remote) was introduced to reduce database load, followed by read‑write separation and master‑slave replication to alleviate database bottlenecks.

While these measures mitigated early bottlenecks, the single‑machine era still suffered from a single point of failure.

Cluster Era

To eliminate the single‑point issue, applications were clustered behind load balancers, providing high availability and better performance. Static‑dynamic separation reduced server load, and CDNs accelerated content delivery across geographic regions.

Redundant clusters for databases, files, caches, applications, load balancers, static content, and CDN services further removed single points, achieving high availability at the cost of increased complexity, resource consumption, and operational overhead.

Distributed Era

With growing business complexity, application splitting became necessary, decoupling services and allowing independent team ownership. Service‑Oriented Architecture (SOA) extracted common functionalities into reusable services.

Message queues were added to handle asynchronous communication and improve throughput, while database sharding distributed data across multiple instances to reduce contention.

Microservices architecture emerged, breaking the system into many small, independently deployable services communicating via lightweight protocols (e.g., REST). Docker provided an ideal runtime environment, offering isolation, fine‑grained resource control, rapid provisioning, and robust orchestration tools.

Despite its benefits—scalability, low coupling, ease of testing—microservices can lead to excessive fragmentation, complex inter‑service communication, and challenges in achieving atomic operations.

In summary, architecture evolves from simple monoliths to sophisticated distributed systems, each era addressing the shortcomings of the previous one while introducing new trade‑offs.

Postscript

The author reflects on personal experience, cites influential works such as "Architecture Talk" by Wang Guikai and O'Reilly's "Software Architecture Patterns," and encourages practitioners to explore and apply these architectural concepts.