An Introduction to Microservice Architecture: Concepts, Evolution, Differences, Practices, and Design Patterns

1. Introduction to Microservice Architecture

Microservice Architecture is an architectural concept that decomposes a system into discrete, independently deployable services, applying SOLID principles at the service level to reduce coupling and increase flexibility.

Concept: Split a large monolithic application into dozens of independent services that can be scaled individually.

Definition: Build applications around business domain components that can be developed, managed, and iterated independently, often using cloud platforms for deployment.

Essence: Use well‑defined, business‑focused services to solve larger problems.

2. Emergence and Development

The term “microservice” appeared in 2012, gained attention in 2014, and became mainstream in 2015, largely promoted by Martin Fowler.

Since then, many forums, blogs, and industry leaders have discussed and practiced microservices, accelerating their adoption.

3. Differences Between Traditional Development and Microservices

Traditional monolithic development packages all functionality into a single WAR file deployed on a JEE container (e.g., Tomcat, JBoss, WebLogic), containing DAO, Service, UI, etc.

Advantages of monoliths: Simple development, centralized management, no external dependencies, local execution without network overhead.

Disadvantages of monoliths: Low efficiency, difficult maintenance, inflexibility, long build times, poor stability, limited scalability.

Key system architecture drivers include agility, user experience, and cost reduction.

Microservice‑based design aims to split applications for agile development and deployment.

4. Specific Characteristics of Microservices

Official definition:

Multiple independent services compose a system.

Each service is deployed separately, running in its own process.

Each service is developed around a specific business capability.

Distributed management.

Strong isolation.

General standards:

Distributed services form the system.

Organization by business, not technology.

Focus on building products rather than projects.

Smart endpoints and dumb pipes.

Automated operations (DevOps).

High fault tolerance.

Rapid evolution and iteration.

5. Differences Between SOA and Microservices

1. Reuse vs. Rewrite: SOA emphasizes reuse and an Enterprise Service Bus; microservices favor rewriting modules to achieve independence.

2. Horizontal vs. Vertical Services: SOA often layers services (e.g., Service Layer, Data Access Layer); microservices provide vertically scoped, end‑user‑facing services.

3. Top‑down vs. Bottom‑up Design: SOA defines contracts up front and manages services centrally; microservices adopt a bottom‑up, agile approach, extracting services as needed.

6. Practical Implementation of Microservices

Key questions:

How do clients access services?

How do services communicate?

How to manage a large number of services?

How to handle service failures?

Client access: Use an API Gateway to provide a unified entry point, aggregate services, and enforce security, rate‑limiting, etc.

Service‑to‑service communication: Synchronous (REST with Spring Boot, RPC such as Thrift/Dubbo) and asynchronous messaging (Kafka, Notify, MetaQ).

Service discovery: Register services in Zookeeper (or similar) and use heartbeats for health checks; clients discover services via the registry.

Failure handling: Implement retries, rate limiting, circuit breakers (e.g., Netflix Hystrix), load balancing, and fallback caching.

7. Common Design Patterns and Applications

Key concerns include API Gateway, service communication, service discovery, fault tolerance, deployment, and data access.

Six typical microservice design patterns:

Aggregator pattern – combines multiple services into a composite service or UI.

Proxy pattern – delegates requests and may transform data.

Chain pattern – services call each other sequentially, forming a processing pipeline.

Branch pattern – parallel chains of services are invoked.

Data‑shared pattern – limited sharing of caches or databases between tightly coupled services (generally an anti‑pattern).

Asynchronous messaging pattern – uses message queues instead of synchronous REST/RPC calls.

8. Advantages and Disadvantages

Advantages: Controllable complexity, independent scaling, technology‑agnostic, fault‑tolerant, high availability, faster deployments, and continuous delivery.

Disadvantages: Increased operational overhead, inter‑service communication cost, data consistency challenges, complex testing, potential duplication of effort, and the need for sophisticated monitoring and DevOps practices.

9. Thought Shift

Adopting microservices requires a mindset change: technology is a means, not an end; the focus should be on business logic, product longevity, full‑stack ownership, single‑responsibility principle, containerization (Docker), and DevOps culture.

10. References and Recommended Reading

http://kb.cnblogs.com/page/520922/

http://www.infoq.com/cn/articles/seven-uservices-antipatterns

http://www.csdn.net/article/2015-08-07/2825412

http://blog.csdn.net/mindfloating/article/details/45740573

http://blog.csdn.net/sunhuiliang85/article/details/52976210

http://www.oschina.net/news/70121/microservice