Comprehensive Overview of Web System Architecture Layers and Design Considerations

In the diagram above we describe the components of a web system architecture and list common technologies for each layer, noting that the architecture is flexible and not every layer or technology is required for every project.

Key points include:

The architecture can be adapted to specific needs; for example, a simple CRM may not need a K‑V cache or a load‑balancing layer if traffic is low.

Traditional HTTP request/response is unsuitable for high‑load inter‑service communication due to latency and unnecessary overhead; it is better reserved for client‑to‑server interactions (WEB, iOS, Android).

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

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

2. Load Distribution Layer

Load balancing spreads external traffic across multiple internal processing nodes. Real‑world analogies include traffic control during rush hour or bank queue systems. For large‑scale web services (hundreds of millions of daily page views), a single server is insufficient, so requests must be distributed to many servers.

Typical software load‑balancing solutions include:

Standalone Nginx or HAProxy

LVS (DR) + Nginx

DNS round‑robin + LVS + Nginx

Intelligent DNS (DNS routing) + LVS + Nginx

Future articles will dive into each of these designs and their variations.

3. Business Service Layer and Communication Layer

3.1 Overview

The core business layer hosts services such as order processing, construction management, medical treatment, payment, and logging. In medium‑to‑large systems these services are decoupled: a system knows about underlying support services (e.g., authentication) but not about peer systems. Complex workflows often require one service to invoke several others, forming a directed call graph.

Communication between services will be explored using Alibaba's Dubbo framework, AMQP‑based message queues, and Kafka, with emphasis on selection criteria.

3.2 Why HTTP Is Not Recommended for Inter‑Service Calls

HTTP establishes a TCP connection for each call, incurs header overhead, lacks built‑in governance, and can waste bandwidth under high load. Although connection pooling (e.g., Apache HttpComponents) mitigates some latency, fundamental inefficiencies remain, so HTTP should be limited to client‑to‑server scenarios.

4. Data Storage Layer

Data storage is the next major focus. It includes initial data, intermediate computation results, and final outputs. We first illustrate basic file‑system concepts on a CentOS 6.5 host.

4.1 File‑System Basics

Partition the disk with fdisk (illustrated in the diagram).

Create a file system (Ext3, Ext4, LVM, XFS, Btrfs) using mkfs .

Mount the file system to a mount point.

Verify with df .

Physical blocks (typically 512 bytes) are the smallest addressable units; multiple sectors compose a block. File‑system implementations hide these details from users.

4.2 Block Storage vs. File Storage

Block storage provides scalable capacity, high throughput, and strong stability but does not natively support file sharing. Technologies such as iSCSI transport SCSI commands over TCP/IP, trading performance for cost.

File storage moves the file system to a remote server (e.g., FTP, NFS, DAS). It enables sharing across multiple clients but offers lower throughput compared to block storage.

4.3 Object Storage

Object storage combines the high throughput of block storage with the sharing capabilities of file storage. Examples include MFS, Swift, Ceph, and Ozone. Object stores treat files as objects with metadata, use distributed metadata servers, and often employ decentralized coordination nodes.

4.4 Database Storage

Future posts will cover MySQL architecture, performance tuning, InnoDB internals, and scaling strategies, as well as NoSQL options such as Cassandra, HBase, and MongoDB.

5. Evaluating Architecture Characteristics

Construction Cost : Balancing design, hardware, operation, and third‑party service expenses.

Scalability / Planning : Enabling horizontal and vertical expansion with minimal disruption.

Attack Resistance : Designing for prevention, concealment, and rapid mitigation of DoS/DDoS and insider threats.

Disaster Recovery : Implementing cluster, distributed, and geo‑redundant recovery mechanisms.

Business Adaptability : Selecting SOA components, message queues, or other middleware based on concrete use cases.

Maintenance Complexity : Reducing operational overhead through thoughtful design.

6. Other Notes

Detailed designs for the load layer, business layer, communication layer, and data‑storage layer will be covered in subsequent articles. A future piece will also discuss data‑analysis architecture, focusing on the Hadoop ecosystem.