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.
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.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
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.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
