Microservice Architecture: Deployment Patterns, Cross‑Cutting Concerns, API Gateways, Service Discovery, Circuit Breakers, Data Management and Anti‑Patterns

Developers familiar with the classic "Design Patterns" book will recognize many of the same patterns when applied to microservices, and the article outlines several typical patterns used in cloud‑native architectures.

Deployment Patterns

Microservice deployment is highly flexible; common options include:

Multiple services sharing a host or virtual machine.

Single service deployed on a dedicated host or virtual machine.

Single service deployed in a single Docker container.

Serverless deployment (e.g., AWS Lambda).

Using a service‑deployment platform such as Kubernetes, Docker Swarm, Mesos, or AWS ECS.

Each approach has its pros and cons, but container orchestration platforms are strongly recommended for flexible deployment solutions.

Horizontal Concerns

During microservice development, teams often spend considerable effort on cross‑cutting concerns that affect every service, such as configuration management, log aggregation, health checking, metrics collection, and distributed tracing. Stable microservice frameworks like Java Spring Boot or Go Micro can help address these issues.

API Gateway

An API gateway acts as a service proxy, providing a unified entry point for all client requests. Open‑source gateways include:

Kong ( github.com/Mashape/kong )

APIAxle ( http://apiaxle.com/ )

Tyk ( tyk.io )

apiGrove ( http://apigrove.net/ )

WSO2 API Manager ( http://wso2.com/products/api-manager/ )

Service Discovery

Service discovery determines how clients or gateways locate microservice instances. Two main approaches are:

Client‑side discovery.

Server‑side discovery (often integrated with the API gateway).

Popular open‑source service‑registry solutions include Apache Zookeeper, Consul, and Etcd.

Circuit Breaker

When a service becomes unhealthy or network latency spikes, calls can block and exhaust resources. A circuit‑breaker proxy returns errors for unhealthy services, preventing further calls until the service recovers. Netflix Hystrix ( github.com/Netflix/Hystrix ) provides this functionality.

Data Management

Designing microservices requires deciding whether each service owns its own database or shares a database. Independent databases enable full decoupling and technology diversity but hinder data sharing, while shared databases simplify maintenance but increase coupling and reduce flexibility.

Microservice Anti‑Patterns

Common pitfalls to avoid include:

Aggregation chaos : Allowing services to become overly large or overly dependent on each other, violating high cohesion and low coupling.

Neglecting automation : Insufficient CI/CD, testing, and deployment automation undermines microservice success.

Layered architecture : Over‑layering (e.g., a universal data‑access layer) creates unnecessary dependencies; services should be business‑centric and self‑contained.

Customer‑driven approval : Relying on client sign‑off for each service version prevents automated testing across all scenarios.

Manual configuration management : Configuration should be automated, not manually edited.

Ignoring versioning : A single version for the whole system leads to incompatibility; APIs must remain backward compatible.

Creating a gateway per service : Over‑provisioning gateways is inefficient and unnecessary.

References

microservices.io/patterns

infoq.com/articles/seve

Original article: https://zhuanlan.zhihu.com/p/82766182