Mastering Multi‑Layer Web Architecture: Load Balancing, Service Layers, and Storage

1. Architecture Layer Diagram

We describe the components of a web system architecture and list common technology stacks for each layer, noting that the architecture is flexible and not every layer is required for every project.

The architecture can be simplified for small CRM systems that may not need a KV cache or load‑balancing layer.

Business‑to‑business communication avoids traditional HTTP due to its high latency and unnecessary overhead.

Caching systems like Redis are treated as a key‑value database in the data storage layer.

Layers are not strictly coupled; for example, image requests can bypass the business layer and go directly to a distributed file system.

2. Load Distribution Layer

The load‑balancing concept spreads external traffic across internal processing nodes. Real‑world analogies include traffic control during rush hour or airport flow management.

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

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

Common load‑balancing solutions include:

Standalone Nginx or HAProxy

LVS (DR) + Nginx

DNS round‑robin + LVS + Nginx

Intelligent DNS + LVS + Nginx

Future articles will detail each scheme.

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 only the services it directly depends on.

Complex business flows often require inter‑service calls (e.g., A calls B after success, or A calls C on failure). This necessitates a communication layer.

3.2 The HTTP Approach (and Why It’s Not Preferred)

Many wonder why HTTP isn’t used for inter‑service communication. HTTP incurs a TCP handshake, request/response latency, and extra header traffic, which wastes resources in high‑load scenarios.

Issues include:

TCP connection setup and teardown add overhead.

Header exchange carries little business value, consuming bandwidth.

Stateless HTTP lacks built‑in governance for context consistency across services.

Even with connection pooling (e.g., Apache HTTP Components), fundamental inefficiencies remain.

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

4. Data Storage Layer

4.1 File Storage Principles

Creating an Ext4 filesystem on CentOS illustrates basic storage steps:

Partition the disk with fdisk.

Create the filesystem with mkfs (Ext3, Ext4, LVM, XFS, Btrfs, etc.).

Mount the filesystem to a directory.

The process shows that physical blocks (typically 512 bytes) are the smallest addressable unit, aggregated into sectors and managed by the OS via the filesystem.

4.2 Block Storage vs. File Storage

Block storage offers high throughput and stability, while file storage provides network sharing at lower cost. Two main requirements drive storage design:

Scalable capacity without disrupting existing data.

Shared access for multiple servers.

4.2.1 Block Storage Systems

Block storage separates the disk media from the host, transmitting I/O commands over networks (e.g., FC, SCSI). The host still sees a local block device, but the underlying I/O travels via fiber or Ethernet (iSCSI). Block storage excels at large capacity, high throughput, and strong stability, but typically does not support native file sharing.

4.2.2 File Storage Systems

File storage moves the filesystem to a remote server accessed via protocols such as NFS, FTP, or NAS. The client issues file‑level operations, which the remote server translates into block I/O. File storage prioritizes sharing over raw performance.

When faced with massive read/write pressure, file storage is not the primary choice; block storage is preferred, though it brings higher cost and operational complexity.

4.3 Object Storage Systems

Object storage combines the high throughput of block storage with the sharing capabilities of file storage. Examples include MFS, Swift, Ceph, and Ozone. Object storage separates metadata (handled by metadata servers) from data (stored on OSD nodes) and typically employs decentralized coordination.

5. Evaluating Architecture Characteristics

5.1 Construction Cost

Implementation incurs design, hardware, operational, and third‑party service costs. Architects must balance budget constraints with business requirements and avoid over‑design.

5.2 Scalability / Planning

Systems should support horizontal and vertical scaling with minimal disruption, allowing upgrades without affecting users.

5.3 Attack Resistance

Good architecture mitigates both external (DoS/DDoS) and internal threats through layered defenses, credential management, and concealment of critical assets.

5.4 Disaster Recovery Levels

Recovery strategies span cluster‑level failover, distributed fault tolerance, and geographically separated sites, each with increasing complexity to preserve data integrity.

5.5 Business Adaptability

Architecture choices must serve current business needs; for example, high‑latency services may use asynchronous message queues (AMQP) instead of synchronous HTTP calls.

5.6 Maintenance Difficulty

Operational overhead grows with system complexity; architects should consider ease of maintenance and required expertise.

Source: JAVA入门 Link: https://blog.csdn.net/yinwenjie/article/details/46480485