Evolution of System Architecture: From LAMP to Distributed Services and Service Governance

Note: Architecture determines system stability, scalability, and concurrency; its evolution moves from simple to complex, single to composite, reflecting accumulated experience and technical refinement.

Initial Stage Architecture

All resources—applications, databases, files—are hosted on a single server, commonly referred to as a LAMP stack (Linux, Apache, MySQL, PHP). This low‑cost setup is the starting point for many small systems.

Separation of Application and Data Services

When traffic grows, a single web server becomes a bottleneck, prompting the addition of a separate web server and the deployment of applications, databases, and files on independent machines, improving concurrency and storage capacity.

Using Caching to Improve Performance

Frequently accessed data (≈20% of data handling 80% of requests) is stored in cache servers—local or distributed—to reduce database load and latency.

Application Server Clustering

After sharding databases, further traffic spikes are handled by adding multiple web servers behind a load balancer, turning a single‑point system into a scalable cluster.

Database Read/Write Separation

When write operations become a contention point, read/write separation distributes load across multiple database instances, improving throughput.

Reverse Proxy and CDN Acceleration

CDN and reverse‑proxy caches accelerate content delivery and offload backend servers, especially for geographically dispersed users.

Distributed File System and Distributed Database

When data volume outgrows a single server, sharding and eventually distributed databases and file systems are employed to sustain growth.

Using NoSQL and Search Engines

Complex data retrieval needs lead to the adoption of NoSQL stores and search engines, accessed via a unified data‑access layer.

Business Splitting

Systems are decomposed by business domain, deploying vertical (independent web apps) and horizontal (shared services) splits, often coordinated via hyperlinks or message queues.

Distributed Services

Common modules are extracted as distributed services consumed by multiple applications, but this introduces challenges such as URL management, dependency complexity, capacity planning, and fault isolation.

Java Distributed Application Fundamentals

Key Technologies for Distributed Services: Message Queue Architecture

Message queues decouple subsystems by passing messages that can be processed asynchronously.

Key Technologies: Service Framework Architecture

Service frameworks expose interfaces to reduce coupling; they suit homogeneous systems such as mobile, web, or external integrations.

Key Technologies: Service Bus Architecture

Service buses provide a bus‑style model for both homogeneous and heterogeneous internal systems.

Communication Patterns in Distributed Architecture

Five patterns are described: synchronous request/response, asynchronous callback, future (async with result handle), one‑way, and reliable (message‑centered persistence and retry).

Implementation of Communication Patterns

Examples include synchronous point‑to‑point, asynchronous point‑to‑point (two variants), and asynchronous broadcast.

Service Governance in Distributed Architecture

Governance ensures high‑quality service provision, allowing traffic routing, consumer protection, rate limiting, and graceful degradation.

Using Dubbo, governance features include service management (enable/disable, weight, version), monitoring (QPS, latency, peak), routing, and protection.

Using Oracle Service Bus (OSB), similar governance capabilities are provided for internal systems.

Disclaimer: Content is sourced from the internet; the original author is anonymous and the material is for learning reference only.

For more technical e‑books, scan the QR code or search “ICT_Architect”.