Designing Scalable Web System Architecture: Layers, Load Balancing, and Storage Strategies

1. Architecture Layer Diagram

Below is a diagram of the web system architecture components, showing typical technology stacks for each layer.

Architecture is flexible; not every layer’s technology is required for every project (e.g., a simple CRM may skip caching or load‑balancing).

The business‑to‑business communication layer avoids traditional HTTP due to high latency and unnecessary overhead; HTTP is mainly for client‑to‑server calls (WEB, iOS, Android).

Caching systems like Redis are treated as part of the data storage layer because they are essentially key‑value databases.

Layers are not strictly dependent; for example, static image requests may bypass the business layer and go directly to a distributed file system, and load balancers can interact directly with the storage layer (e.g., LVS with MySQL).

2. Load Distribution Layer

Load balancing distributes external traffic across multiple internal processing nodes, similar to traffic control in daily life.

In large‑scale web services (hundreds of millions of daily PV), multiple servers handle the same business, requiring a design that routes client requests to available nodes.

The load layer also routes different request types to appropriate services (e.g., image requests go to storage, order submissions go to the order service).

Different business needs dictate different load‑balancing solutions; Nginx handles HTTP, while HAProxy or TCP‑Proxy modules are needed for raw TCP traffic.

Common load‑balancing architectures include:

Standalone Nginx or HAProxy

LVS (DR) + Nginx

DNS round‑robin + LVS + Nginx

Smart DNS (DNS routing) + LVS + Nginx

Future articles will detail these schemes.

3. Business Service and Communication Layers

3.1 Overview

The core business layer includes order processing, construction management, medical services, payment, logging, etc., and requires decoupling between subsystems so that one system can operate without knowing the internal details of another.

Complex workflows often involve chained calls between services (A → B, A → C, or A & D needing simultaneous success).

Subsequent articles will explore Alibaba’s Dubbo, AMQP‑based message queues, and Kafka for communication layer choices.

3.2 Why Not HTTP?

HTTP incurs high latency due to TCP connection setup/teardown, unnecessary header exchange, and lacks built‑in context propagation for SOA, making it inefficient for high‑load inter‑service calls.

Therefore, HTTP is recommended only for client‑to‑server interactions (WEB, iOS, Android), not for service‑to‑service communication.

4. Data Storage Layer

The storage layer covers initial data, intermediate results, and final outputs, with classifications illustrated in a mind map.

4.1 File System Basics

Example steps on a CentOS 6.5 system: partitioning with fdisk, creating a filesystem with mkfs, mounting, and verifying with df.

4.2 Block vs. File Storage

Block storage provides scalable capacity, high throughput, and stability but lacks native file sharing; file storage offers network‑shared access but lower throughput.

4.2.1 Block Storage Systems

Block I/O commands are transmitted over networks (e.g., FC, SCSI, iSCSI) while the filesystem mapping remains local, making block storage unsuitable for direct file sharing.

4.2.2 File Storage Systems

Remote file systems (FTP, NFS, DAS) encapsulate block I/O with network protocols, enabling shared access across multiple servers.

When faced with heavy read/write pressure, block storage is preferred; however, its cost and operational complexity may lead to choosing file storage for shared scenarios.

4.3 Object Storage Systems

Object storage combines block storage’s performance with file storage’s sharing and cost benefits; examples include Swift, Ceph, and Ozone.

Object storage is a distributed file system, though not all distributed file systems qualify as object storage.

5. Evaluating Architecture Characteristics

Key evaluation points include construction cost, scalability, attack resistance, disaster recovery levels, business adaptability, and maintenance difficulty.

6. Additional Notes

Detailed designs for load, business, and storage layers will be covered in future articles.

Data analysis layers (e.g., Hadoop ecosystem) are also relevant for large‑scale systems.

Source: http://blog.csdn.net/yinwenjie/article/details/46480485