Why Microservices Matter: Evolution, Challenges, and Best Practices

This article explains how microservices evolved from monolithic systems, compares them with SOA, discusses data fragmentation, CAP theory, distributed transactions, service partitioning, circuit breakers, API gateways, configuration management, tracing, and reviews popular frameworks like Spring Cloud and Dubbo.

IT Architects Alliance
IT Architects Alliance
IT Architects Alliance
Why Microservices Matter: Evolution, Challenges, and Best Practices

1. Birth of Microservices

Microservices evolved from the divide‑and‑conquer idea. Traditional monolithic systems could no longer meet the fast‑changing market demands, leading from monolith to distributed architecture, then to SOA, and finally to microservices where services are split into increasingly smaller granularity.

2. Difference between Microservices and SOA

Microservices are truly distributed and decentralized. All routing, message parsing and other logic reside inside each service, removing a centralized ESB. Communication is lightweight (typically HTTP REST), making the split more thorough than classic SOA.

3. Problems Caused by Microservice Architecture

Data fragmentation across services creates two main issues: (1) how to perform complete data queries (e.g., pagination, multi‑condition) when data is split, and (2) how to run analytics on full data without affecting live services. Two technical approaches are online processing via service APIs (which adds heavy coding and performance impact) and offline processing by synchronizing data to another store for aggregation.

Offline processing is recommended: use Spring Boot and MongoDB to sync data from N services into a MongoDB cluster, clean the data during sync, and expose a dedicated API for reporting, thus avoiding impact on the primary services.

4. CAP Theory

Consistency, Availability, Partition‑tolerance. In distributed systems, the CAP theorem applies; microservice systems are usually AP (available and partition‑tolerant) rather than CA.

5. Distributed Transactions

Typical solutions are two‑phase commit (2PC) or three‑phase commit (3PC). Both suffer from failure scenarios that often require manual recovery. 2PC works as follows: the coordinator starts a transaction, asks all participants to prepare, participants write undo/redo logs, then the coordinator decides to commit if all prepared successfully or roll back otherwise. Because of blocking and performance penalties, distributed transactions should be minimized.

6. Service Partitioning

Horizontal partitioning splits services by business domain (order, marketing, risk, points, etc.). Vertical partitioning extracts independent components from a single business function into atomic services. A layered approach separates core and common capabilities into stable service cores, enabling rapid front‑end response to market changes.

7. Circuit Breaker

To prevent cascade failures, circuit breakers monitor failure rates. When failures stay below a threshold, the breaker stays closed and requests pass through. If failures exceed the threshold, the breaker opens, causing immediate fast‑fail responses. After a cool‑down period, it moves to half‑open, allowing limited requests to test recovery before closing again. Circuit breakers also provide isolation, degradation, and self‑healing.

8. API Gateway

Gateways (e.g., Zuul, Nginx) expose a unified API surface, hide internal services, enforce authentication/authorization, provide logging, monitoring, and traffic throttling. High availability of the gateway is critical to avoid it becoming a bottleneck.

9. Centralized Configuration Management

Tools such as Spring Cloud Config, Alibaba Diamond, Baidu Disconf, or Ctrip Apollo manage configuration files across services.

10. Distributed Tracing

Tracing components (Google Dapper, Twitter Zipkin, Alibaba EagleEye) track request flow across services, making debugging easier.

11. Microservice Frameworks

Common frameworks include Spring Cloud, Dubbo, and Kubernetes. Spring Cloud offers faster development and deployment, relies on HTTP REST, and integrates many Netflix OSS components (Eureka, Ribbon, Hystrix, Zuul). Dubbo uses RPC, XML configuration, and focuses on service governance.

12. Spring Cloud Core Components

Eureka – service registration and discovery

Hystrix – circuit breaker

Ribbon – client‑side load balancing

Zuul – routing gateway

Spring Cloud Config – centralized configuration

Spring Cloud Security – authentication/authorization (often with OAuth2)

Spring Cloud Sleuth – distributed tracing (wraps Dapper, Zipkin, etc.)

Spring Cloud Stream – messaging abstraction (RabbitMQ, Kafka, Redis, etc.)

A typical Spring Cloud microservice system consists of Eureka, Zuul, Config, and an Auth service.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

Distributed SystemsCAP theoremSpring Cloudcircuit breakerservice partitioning
IT Architects Alliance
Written by

IT Architects Alliance

Discussion and exchange on system, internet, large‑scale distributed, high‑availability, and high‑performance architectures, as well as big data, machine learning, AI, and architecture adjustments with internet technologies. Includes real‑world large‑scale architecture case studies. Open to architects who have ideas and enjoy sharing.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.