Evolution and Key Concepts of Distributed Architecture

1. History of Distributed Architecture

In 1946 the world’s first electronic computer, ENIAC, was built at the University of Pennsylvania, marking the beginning of the computer era and laying the foundation for later Internet development.

The computer consists of five parts—input devices, output devices, memory, an arithmetic‑logic unit, and a control unit—described by the von Neumann model, and operates via data, instruction, and control flows.

After ENIAC, IBM dominated the mainframe era. The first IBM System/360 appeared in 1964, leading IBM to dominate large‑scale computing in the 1950s‑60s. During this period, architectures diverged into CISC‑based cheap PCs and RISC‑based high‑performance UNIX servers.

Mainframes offered high performance, stability, and security, but centralized systems introduced problems: high cost, complexity, single‑point failures, and limited scalability as personal PCs became cheaper and more powerful.

Alibaba’s 2009 “IOE” Migration

IOE refers to IBM mini‑computers, Oracle databases, and EMC storage. Alibaba’s rapid growth exposed the scalability limits of the centralized Oracle‑based architecture, prompting a move away from IOE.

Common Distributed Architecture Concepts

Cluster : Like hiring a second chef when the kitchen becomes busy, multiple identical servers work together to handle load.

Distributed : Adding a dedicated prep cook to let chefs focus on cooking mirrors a distributed system where specialized nodes handle specific tasks.

Node : An independent process that follows distributed protocols, typically a process on an operating system.

Replication Mechanism

Data replication stores identical data on multiple nodes to provide redundancy; service replication offers the same service from several nodes using a master‑slave model for high availability.

Middleware

Middleware sits between the operating system and applications, simplifying communication, I/O, and other services for developers.

Architecture Evolution Process

A mature large‑scale website architecture evolves through stages as user volume and business functions grow, prompting changes in development models and technology stacks.

Typical functional modules include user management, product catalog, and transaction processing.

Stage 1: Single‑Application Architecture

Both application and database run on a single server.

Stage 2: Separate Application and Database Servers

Separating the servers improves performance, scalability, and fault tolerance as traffic grows.

Stage 3: Application Server Cluster – Load Balancing

Introducing a cluster distributes requests, but raises questions about request routing and session management.

Stage 4: Database Read‑Write Separation

Read operations are directed to replicas while writes go to the master, requiring master‑slave replication (e.g., MySQL) and possibly third‑party middleware such as Mycat.

Stage 5: Search Engine to Alleviate Read Load

Search engines improve fuzzy query performance but introduce indexing overhead.

Stage 6: Caching Layer (Redis, Memcached)

Hot data can be cached at the application layer; in some scenarios NoSQL stores like MongoDB replace relational databases.

Stage 7: Horizontal/Vertical Database Sharding

Vertical sharding splits different business data into separate databases; horizontal sharding partitions a single table across multiple databases to overcome size limits.

Stage 8: Application Decomposition

As business complexity grows, applications are split into subsystems (e.g., user, product, transaction) based on domain models, extracting common code into shared services.

After service decomposition, inter‑service communication can use RPC technologies such as WebService, Hessian, HTTP, or RMI.