From LAMP to Distributed Microservices: A Journey of System Architecture Evolution

Initial Stage Architecture – LAMP

In the early stage, a small system hosts the application, database, and files on a single server, commonly referred to as a LAMP stack. The operating system is Linux, the application is developed with PHP and deployed on Apache, and the database uses MySQL.

Application and Data Service Separation

When traffic grows, the single web server becomes a bottleneck. To alleviate pressure, the application, database, and files are deployed on separate resources, improving concurrency handling and storage capacity.

Performance Improvement with Caching

Feature: Frequently accessed data (about 20% of the total) is stored in a cache server, reducing database load. Both local and distributed caches are used; local caches are faster but limited in size and may compete for memory with the application.

Application Server Clustering

After sharding databases, the system still experiences slowdowns due to Apache request queuing. Adding multiple web servers behind a load balancer distributes traffic, increasing concurrent processing capacity and removing the single‑server bottleneck.

Database Read/Write Separation

High write and update loads cause resource contention. Separating read and write operations across multiple servers further distributes load and improves performance.

Reverse Proxy and CDN Acceleration

Feature: Using a CDN and reverse proxy speeds up user access and reduces backend load by caching static content closer to users.

Distributed File System and Distributed Database

As data volume grows, a single server can no longer meet performance needs. The system adopts a distributed database and distributed file system, splitting databases and tables to handle massive scale.

NoSQL and Search Engine Integration

Feature: Introducing NoSQL databases and search engines addresses complex data storage and retrieval requirements, allowing the application layer to access diverse data sources through a unified module.

Business Splitting

Feature: The system is refactored by business lines. Vertical splitting creates independent web applications for distinct business domains, while horizontal splitting extracts reusable services deployed as distributed services.

Distributed Services

Common application modules are extracted and deployed on distributed servers for other services to invoke. This reduces coupling but introduces challenges such as URL configuration, service dependency management, capacity planning, communication overhead, and fault isolation.

Key Technologies for Distributed Applications

Message Queue Architecture: Decouples subsystems by passing messages, allowing different components to process the same message.

Message Queue Principles: (Image omitted for brevity)

Service Framework Architecture: Provides point‑to‑point interfaces for homogeneous systems, suitable for mobile, internet, and external applications.

Service Framework Principles: (Image omitted for brevity)

Service Bus Architecture: Offers a bus‑style model for both homogeneous and heterogeneous systems, primarily for internal use.

Service Bus Principles: (Image omitted for brevity)

Communication Patterns in Distributed Architecture

The five patterns include request/response (synchronous), callback (asynchronous), future, oneway, and reliable mode (message persistence and retry).

Service Governance

Governance ensures high‑quality service provision, including traffic routing, consumer protection, service management (registration, upgrade, downgrade, weight adjustment), and monitoring (request count, latency, peak usage). Dubbo is highlighted as a high‑performance RPC framework used for service governance.

Source: http://www.jianshu.com/p/ab35b6d74fed