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

1. System Architecture Evolution

With the rapid growth of the Internet, application scale and demand have increased, forcing system architectures to evolve from single‑application monoliths to vertical splitting, distributed services, SOA, and the current microservice wave.

1.1 Centralized Architecture

When traffic is low, a single application containing all functions is deployed to reduce nodes and cost. This three‑tier (presentation, business, data) monolithic model runs in one process on one machine.

Easy to develop

Easy to test

Easy to deploy

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

1.2 Vertical Split

As traffic grows, the monolith is split by business function, achieving load distribution, module‑level optimization, and better horizontal scaling.

Pros: traffic sharing, independent optimization, easier scaling and fault tolerance.

Cons: duplicated development effort across independent systems.

1.3 Distributed Services

When vertical applications multiply, core business is extracted into independent services, enabling reuse and faster response to market changes. Distributed calls become essential.

Pros: increased code reuse and development efficiency.

Cons: higher coupling between services, complex call relationships.

1.4 Service Governance (SOA)

SOA

Originally created to integrate disparate enterprise systems, emphasizing service reuse and a message bus, but suffers from heavy centralization and limited decentralization.

Microservices

Goal: help enterprises respond quickly to change; principle: decentralization.

Key governance tasks include service registration, automatic subscription, and dynamic health monitoring.

1.5 Microservices

Microservices differ from SOA by focusing on small, single‑responsibility services that expose REST APIs, are autonomous, and can be developed with any technology stack.

Characteristics

Single responsibility per service

Very small granularity ("micro")

Service‑oriented (API‑first)

Autonomous teams and technology choices

Independent deployment and scaling

Design Principles

High cohesion, low coupling

Lightweight communication (RESTful HTTP or async messaging)

Database per service (no shared DB)

High Autonomy

Independent deployment and runtime

Independent development and evolution

Team ownership of the full service lifecycle

Business‑Centric

Each service encapsulates a specific business capability

Clear bounded contexts and team alignment

Resilience

Design for fault tolerance (circuit breakers, fallback, rate limiting)

Service isolation and graceful degradation

2. Remote Call Methods

Both SOA and microservices need remote invocation. Common approaches are RPC and HTTP.

2.1 Understanding RPC

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

Key points:

Transport protocol is usually TCP.

Data format must be agreed upon and serialized.

Calls are encapsulated so the client sees a local‑like API.

Typical RPC frameworks include Dubbo, gRPC, and traditional RMI.

Reference links: blog.csdn.net/zpoison/article/details/80729052, www.dockone.io/article/394,<|message|>qinnnyul.github.io/2018/08/20/microservice-design-principal/

Overall, the article provides a comprehensive overview of how backend systems have transitioned from monolithic designs to highly decoupled microservice architectures, the principles guiding this evolution, and the practical techniques (service governance, remote calls, automation) required to operate them at scale.