Microservice Architecture Evolution: From Monolith to Service Mesh and Best Practices

Microservice architecture and its components are introduced, explaining what they are and why they are used, with a focus on a high‑level view rather than implementation details.

To understand microservices, the article first contrasts them with monolithic applications, using a fictional online supermarket built by Xiao Ming and Xiao Pi as an example.

The initial requirements are simple: a public website for browsing and purchasing goods, and an admin backend for managing users, products, and orders.

Website: user registration/login, product display, ordering

Admin backend: user management, product management, order management

After a quick launch, business growth leads to additional marketing activities, a mobile app, and data analysis, causing the system to become tangled: duplicated code, unclear service boundaries, shared database bottlenecks, and difficult deployments.

To address these issues, the team abstracts common capabilities into independent services: User Service, Product Service, Promotion Service, Order Service, and Data‑Analysis Service, removing most redundant code.

Although services are separated, the database remains shared, still causing performance bottlenecks and coupling.

Database becomes a single point of failure and performance bottleneck.

Data management becomes chaotic as services directly query each other's tables.

Schema changes affect multiple services.

The database is then split per service, and a message‑queue layer is added to improve real‑time processing.

Each service can now use heterogeneous storage (e.g., a data‑warehouse for analytics, caches for high‑traffic services).

Beyond code, the article discusses operational components needed for a reliable microservice system:

Monitoring: Use exporters (Redis, MySQL) and Prometheus + Grafana to collect metrics and trigger alerts.

Distributed Tracing: Propagate traceId, spanId, parentId, request/response times via HTTP headers; implement with Zipkin (based on Google Dapper).

Log Analysis: Deploy ELK (Elasticsearch, Logstash, Kibana) to aggregate and search logs across instances.

Gateway: Central entry point for permission checks and API documentation; coarse‑grained gateway chosen for the small number of services.

Service Registration & Discovery: Automatic registration of instances, health checking, and client‑side load balancing (e.g., ZooKeeper, Eureka, Consul, etcd).

Circuit Breaker, Service Degradation, Rate Limiting: Prevent cascading failures, protect downstream services, and limit abusive traffic.

Testing strategies are divided into three layers:

End‑to‑end testing for critical user flows.

Service‑level testing, often using mock servers.

Unit testing for individual code units.

A custom microservice framework is built to encapsulate common boilerplate (metrics, tracing, logging, registration, routing, circuit breaking) and reduce duplication across services, though framework upgrades can be costly.

Alternatively, a Service Mesh (data plane + control plane) can provide these capabilities without code changes, at the expense of additional latency.

Finally, the article notes that microservice adoption is not an end point; future directions include Serverless/FaaS, and sometimes a return to monoliths is considered.

Overall, the piece provides a comprehensive, practical guide to evolving a monolithic application into a resilient microservice ecosystem.