Evolution of System Architecture and Microservices: From Monoliths to Service Governance

1. System Architecture Evolution

With the rapid growth of the Internet, website applications have expanded in scale, putting pressure on technology and driving continuous evolution of system architecture from single applications to vertical splitting, distributed services, SOA, and the current hot microservice architecture, as well as the emerging Service Mesh.

The article revisits this history, highlights the most popular current architectures, and aims to help aspiring Java engineers understand the past, present, and future.

1.1 Centralized Architecture

When traffic is low, a single application containing all functions reduces deployment nodes and cost. A three‑layer structure (presentation, business logic, data access) is used, but all layers run in the same process on one machine, forming a monolithic application.

Advantages: easy development, testing, and deployment.

Problems: code coupling, difficulty of optimization, lack of horizontal scalability, low fault tolerance, high technology‑selection cost, and long release cycles.

1.2 Vertical Splitting

As traffic grows, a single application cannot meet demand, so the system is split by business function.

Advantages: traffic sharing, module‑level optimization, easier horizontal scaling, load balancing, and higher fault tolerance.

Disadvantages: duplicated development work across independent systems.

1.3 Distributed Services

When many vertical applications exist, core business is extracted into independent services, forming a stable service center that enables rapid front‑end response to market changes.

Advantages: increased code reuse and development efficiency.

Disadvantages: higher coupling between services, complex call relationships, and maintenance difficulty.

1.4 Service Governance (SOA)

SOA originated to solve integration of disparate enterprise systems, emphasizing service reuse and a message bus, but often leads to centralized heavyweight middleware.

Microservices aim for decentralization, focusing on business needs, componentization, and service‑oriented design.

Key governance tasks include service registration and discovery, automatic subscription, and dynamic monitoring of service status.

1.5 Microservices

Microservices differ from SOA by emphasizing small, single‑responsibility services that expose RESTful APIs, are autonomous, and can be developed by independent teams using any technology.

Key characteristics include high cohesion, low coupling, lightweight communication (REST or asynchronous messaging), independent databases, autonomous deployment, business‑centric design, and resilient design (circuit breakers, fallback, self‑protection).

1.6 Differences and Connections between Microservices and SOA

SOA focuses on system integration and service reuse, while microservices extend SOA with stronger componentization, domain modeling, and decentralization.

2. Remote Call Methods

Both microservices and SOA require remote service invocation. Common methods include RPC (e.g., Dubbo) and HTTP/REST.

2.1 Understanding RPC

RPC (Remote Procedure Call) allows a program on one machine to invoke a sub‑program on another machine as if it were local, abstracting network communication details.

Key aspects: network protocol (usually TCP), data format and serialization, and transparent invocation.

The article also mentions monitoring tools (Hystrix, Zipkin, Sleuth), logging solutions (ELK, Splunk, Sumo Logic), and automation practices (CI/CD pipelines, Docker, Terraform, CloudFormation) essential for operating microservice systems.