Microservice Architecture Evolution: From Monolith to Service Mesh

This article introduces microservice architecture and its related components, explaining what they are and why they are used. It focuses on presenting a global view of microservice architecture without delving into detailed usage of each component.

Initial Requirements

A few years ago, Xiao Ming and Xiao Pi started an online supermarket. Their initial needs were simple: a public website for browsing and purchasing products, and a management backend for handling users, products, and orders.

Business Growth and Problems

Rapid competition forced them to add promotional activities, mobile apps, and data analysis, leading to rushed development and a tangled architecture with duplicated code, unclear service boundaries, shared databases, performance bottlenecks, and difficult deployment and testing.

Time for Change

Realizing the issues, they began abstracting common business capabilities into independent services such as User Service, Product Service, Promotion Service, Order Service, and Data Analysis Service.

Partial Refactoring

They split the application logic into separate services but still shared a single database, which retained problems like database bottlenecks and tightly coupled schemas.

Full Refactoring

They further isolated each service's persistence layer, introduced a message queue for real‑time communication, and allowed services to use heterogeneous storage (e.g., a data warehouse for analytics).

Monitoring – Detecting Fault Signs

In high‑concurrency distributed scenarios, faults can erupt suddenly, so a comprehensive monitoring system is needed. Different components (Redis, MySQL, business services) expose metrics via a uniform /metrics interface, which Prometheus scrapes and Grafana visualizes with alerts.

Tracing – Locating Issues

Each user request may traverse multiple services; tracing records the call chain using traceId, spanId, parentId, and timestamps. An open‑source implementation such as Zipkin collects these logs for visual analysis.

Log Analysis

When logs become massive and distributed, a searchable log engine is required. The ELK stack (Elasticsearch, Logstash, Kibana) provides indexing, collection, and UI for querying logs across services.

Gateway – Access Control and Service Governance

A gateway sits between callers and services to enforce permission checks, provide unified API documentation, and optionally route traffic at different granularity levels.

Service Registration and Discovery – Dynamic Scaling

Services register themselves with a discovery system (e.g., Zookeeper, Eureka, Consul, Etcd). New instances are automatically added to load balancers, and unhealthy instances are removed, enabling seamless scaling.

Circuit Breaker, Service Degradation, Rate Limiting

Circuit Breaker

When a downstream service repeatedly fails, the circuit breaker opens to return errors immediately, preventing cascading failures.

Service Degradation

Non‑critical services can be degraded (temporarily disabled) to keep core functionality alive when they fail.

Rate Limiting

Services protect themselves by limiting request rates, optionally per‑caller, to avoid overload after recovery.

Testing

Testing in microservice environments includes three levels: end‑to‑end testing for the whole system, service‑level testing for APIs, and unit testing for code. End‑to‑end tests are costly but provide the highest confidence.

Microservice Framework

A shared framework abstracts common concerns (metrics, tracing, logging, registration, routing, circuit breaking) so individual services can focus on business logic, though framework upgrades can be costly.

Another Path – Service Mesh

Service mesh moves cross‑cutting concerns to sidecar proxies, separating data plane (traffic handling) from control plane (configuration). This reduces code intrusion but may add latency.

Conclusion – A New Beginning

Microservice transformation is not an endpoint; future directions include serverless, FaaS, and possible returns to monoliths. The article ends with the authors reflecting on their journey and planning a short break.