A Comprehensive Overview of Microservice Architecture and Its Evolution

This article introduces microservice architecture and its related components, explaining what they are and why they are used, while focusing on a high‑level view rather than implementation details.

To understand microservices, the article first contrasts them with monolithic applications, using an online supermarket example to illustrate the evolution from a simple single‑server setup to a more complex system.

Initial Requirements

Initially, the founders need a website for browsing and purchasing products and a management backend for handling users, products, and orders. The early architecture consists of a single website and a separate admin backend deployed on a cloud service.

Business Growth and Early Problems

As competition intensifies, new marketing features and a mobile app are added without proper architectural planning, leading to duplicated code, tangled interfaces, unclear service boundaries, performance bottlenecks, shared database issues, and difficult deployments.

Need for Change

Recognizing these problems, the team abstracts common business capabilities into independent services such as User, Product, Promotion, Order, and Data‑Analysis services, reducing code duplication and simplifying the control layer.

However, the shared database still causes performance and coupling issues, prompting a full database split and the introduction of a message‑queue for real‑time communication.

Monitoring – Detecting Fault Signs

In high‑concurrency distributed environments, comprehensive monitoring is essential. Each component exposes a unified metrics endpoint, which Prometheus scrapes and Grafana visualizes, providing alerts for abnormal behavior.

Tracing – Locating Problems

Link tracing records the chain of service calls for each user request, using identifiers like traceId, spanId, parentId, requestTime, and responseTime. The article shows an Istio‑style example and mentions implementing tracing with Zipkin.

Log Analysis

Log aggregation is handled by the ELK stack (Elasticsearch, Logstash, Kibana), allowing centralized search and visualization of logs across all services.

Gateway – Access Control and Service Governance

A gateway sits between callers and services to enforce permissions and provide a unified API surface, with deployment granularity ranging from per‑service to per‑domain.

Service Registration and Discovery – Dynamic Scaling

Automatic service registration and discovery (e.g., via Consul, Eureka, or a custom Redis‑based solution) enables seamless scaling and load‑balancing without manual IP management.

Circuit Breaking, Service Degradation, and Rate Limiting

Resilience patterns such as circuit breaking, graceful degradation, and rate limiting protect the system from cascading failures and overload.

Testing

Testing is organized into three layers: end‑to‑end, service‑level, and unit tests, with mock servers used to isolate service dependencies.

Microservice Framework

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

Service Mesh – An Alternative

Service mesh introduces a sidecar proxy for each service, handling traffic, security, and observability without code changes, but may add performance overhead.

Conclusion

The article concludes that microservice adoption is an ongoing journey, with future directions including serverless, FaaS, or even a return to monoliths, emphasizing continuous evolution.