Microservice Architecture Evolution: From Monolith to Service Mesh

Microservice architecture and its related components are introduced, explaining what they are and why they should be used, with a focus on providing a clear global view rather than detailed implementation.

Understanding microservices starts with recognizing monolithic applications, where all functionalities are packaged into a single unit. The article uses an online supermarket example to illustrate the gradual evolution from monolith to microservices.

Initial requirements: a public website for browsing and purchasing products, and an admin backend for managing users, products, and orders.

After rapid development, the system suffers from duplicated code, tangled interfaces, unclear service boundaries, performance bottlenecks, and deployment difficulties, leading to fragile releases and organizational friction.

To address these issues, common business capabilities are abstracted into shared services: User Service, Product Service, Promotion Service, Order Service, and Data Analysis Service. This reduces redundancy and simplifies backend logic.

Even after service separation, a shared database remains a bottleneck, causing performance issues and tight coupling. Splitting databases per service and introducing a message queue improves isolation and scalability.

Monitoring is essential for early fault detection. Components expose metric endpoints, collected by Prometheus and visualized with Grafana. Example exporters for Redis and MySQL are used.

Link tracing records the call chain of a user request across services, using headers like traceId, spanId, parentId, requestTime, and responseTime. Zipkin is employed as the tracing backend.

Log analysis solves the problem of massive, distributed log files. The ELK stack (Elasticsearch, Logstash, Kibana) is used to collect, store, and visualize logs, with agents forwarding log files to Logstash.

A gateway provides permission control and service governance, acting as a gatekeeper for all inbound and inter‑service calls. The coarse‑grained approach places one gateway per microservice group.

Service registration and discovery enable dynamic scaling. Services register themselves to a discovery system (e.g., ZooKeeper, Eureka, Consul, etcd) and obtain peer addresses automatically.

Circuit breaking, service degradation, and rate limiting protect the system from cascading failures and overload.

Testing is divided into end‑to‑end, service, and unit tests, each with different effort and confidence levels. Mock servers aid service testing, while extensive unit tests provide fast feedback.

A custom microservice framework abstracts common integration code (metrics, tracing, logging, registration, routing, circuit breaking) to reduce duplication, though framework upgrades can be costly.

Service Mesh offers a non‑intrusive alternative by deploying sidecar proxies for traffic handling, separating data plane and control plane, at the expense of additional latency.

The journey concludes with the acknowledgment that microservices are not the final destination; future directions include serverless, FaaS, or even a return to monoliths.