Monolith vs Microservices: Which Architecture Wins in Real‑World Scenarios?

21CTO导读：单体架构有它的优势，微服务有新的优点，各有所长，我们来看它们在技术和参数上的比较。

Microservice architecture was introduced to "combat" monolithic systems by splitting business processes into independent services. For example, a flight‑booking flow that in a monolith is a single method becomes separate services for reservation, credit‑card payment, and confirmation, communicating via defined interfaces.

Round 1: Latency

Every network call between microservices adds at least 24 ms of latency. Assuming 100 ms of processing time, the total latency grows with each additional service call. In contrast, a monolith performs all calls locally, eliminating network delay.

Network latency – microservices vs monolith

When many calls execute in parallel, total execution time decreases, but the monolith remains faster because it has no network overhead. Reducing call‑chain length, using fan‑out patterns, and keeping data local can mitigate latency, yet the physical layer limits microservice performance.

Round 2: Complexity

Microservices increase both development and operational complexity. Codebases grow, multiple languages and frameworks may be used, and version mismatches arise. Logging and tracing become harder because each service writes to separate logs; unique request IDs are needed to correlate events across services.

Running microservices in a Kubernetes cluster adds further complexity, despite its auto‑scaling capabilities.

Round 3: Reliability

Monolithic calls are local, so network failures are impossible. In microservices, each network call typically has 99.9 % reliability; a chain of ten calls drops overall reliability to about 99 %, meaning one failure per hundred calls.

Frameworks such as Spring Cloud, Istio, and chaos‑engineering tools like Netflix’s Chaos Monkey help microservices tolerate failures, but the monolith remains inherently more reliable for many critical systems.

Round 4: Resource Usage

Microservices generally consume more resources per unit of work because each service runs in its own container or VM. However, fine‑grained scaling lets clusters allocate resources only where needed, often reducing overall consumption compared to running multiple monolith instances.

When workloads are bursty, microservices can scale out specific hot components, achieving better cost efficiency.

Round 5: Scalability

Both monoliths and microservices can be scaled horizontally by adding instances. Microservices achieve more precise scaling because only the overloaded service needs extra instances, saving resources and cost.

Round 6: Throughput

Network overhead limits microservice throughput for highly parallel workloads. In purely local, compute‑bound scenarios, a monolith can deliver higher throughput.

Round 7: Deployment Speed

Microservices enable faster, more isolated deployments; changes affect only the targeted service. Monoliths require coordinated releases, which become harder as the codebase grows.

Round 8: Communication & Cost

Microservice teams are often sized by the “two‑pizza rule” (4‑8 developers per service). Smaller teams reduce communication channels dramatically compared to a large monolithic team, improving coordination and speed.

Who wins? The analysis shows the monolith wins twice and microservices win three times. Microservices excel when teams exceed ten developers, require 24/7 reliability, need elastic scaling, or have clearly separable business domains. Monoliths remain suitable for small teams, simple deployments, and latency‑sensitive workloads.

Guidelines for choosing microservices include:

24/7 reliability requirements

Scaling beyond a few requests

Significant load variation

Team size over ten developers

Domain can be split into smaller bounded contexts

Operations can be expressed as REST calls or queue events

No strict cross‑service transaction needs

If these conditions apply, microservices are a strong option for enterprise software.

作者：场长