This a translation of an article ( http://microservices.io/patterns/microservices.html) originally written and copyrighted by Chris Richardson ( http://twitter.com/crichardson).

Pattern: Microservice Architecture

background

Suppose you are developing a server-side application. The application must support a wide variety of clients, including desktop browsers, mobile browsers, and native mobile applications. Applications may also need to expose some APIs for use by third parties, and may also integrate with other applications through web services or message brokers. Applications execute business logic to process requests (HTTP requests or messages); access databases; exchange messages with other systems; and return HTML/JSON/XML type responses.

Applications are either multi-tiered or hexagonal and contain various types of components:

Presentation components - handles HTTP requests in response and returns HTML or JSON/XML (for web service API)
Business logic - the business logic of the application
Database access logic - Data access objects are used to access the database
Application integration logic - Messaging layer, such as Spring-based integration

These logical components respond to different functional modules in the application respectively.

question

What is the deployment architecture of the application?

driving force

The app is maintained by a team of developers
New team members must get started quickly
Applications should be easy to understand and modify
You want to do continuous integration of your application
You must deploy multiple copies of the application on multiple machines to meet scalability and availability requirements
You want to use new technologies (frameworks, programming languages, etc.)

solution

By using the Scale Cube (especially the scaling in the y-axis direction) to structure the application, the application is decomposed into a set of cooperating services by function. Each service implements a limited set of related functions. For example, an application may contain order management services, customer management services, etc.

The services communicate through synchronous protocols such as HTTP/REST or asynchronous protocols such as AMQP.

Services are independently developed and deployed.

Each service has its own database in order to be decoupled from other services. When necessary, consistency between databases is maintained through database replication mechanisms or application-level events.

Example

Let's assume you're building an e-commerce application that receives orders from customers, verifies inventory and availability, and dispatches orders. The application contains several components, including StoreFrontUI, which implements the user interface, and some background services, which are used to check credit limits, maintain inventory, and dispatch orders.

Applications are deployed as a set of services.

result

This scheme has some benefits:

Each microservice is relatively small

Easy for developers to understand
The IDE is more responsive and the developer is more productive
Web containers start faster, developers are more productive, and deployments are faster

Each service can be deployed independently - easy to deploy new versions of services frequently
Easy to scale development organization structure. You can organize the development work of multiple teams. Each (Double Pizza ^[1] ) team is responsible for a single serving. Each team can develop, deploy, and scale services independently of other teams.
Improve fault isolation. For example, if a service has a memory leak, only that service is affected, and other services can still process requests. In contrast, one faulty component of a monolithic architecture can bring down the entire system.
Each service can be developed and deployed individually
Eliminates any long-term commitments to the technologh stack

This solution also has some disadvantages:

Developers have to deal with the additional complexity of distributed systems.

Developer tools/IDEs are geared towards building monolithic applications and do not explicitly provide support for developing distributed applications
test more difficult
Developers need to implement inter-service communication mechanisms
Achieving cross-service use cases without using distributed transactions is more difficult
Achieving cross-service use cases requires careful collaboration between teams

Deployment complexity for production environments. The operational complexity of deployment and management remains for systems that contain many different service types.
Memory consumption increases. The microservice architecture uses NxM service instances instead of N monolithic application instances. If each service is running on its own separate JVM (or similar), it is often necessary to isolate the instance, which is M times the overhead for that many JVMs running. Also, if each service runs on a separate VM (like an EC2 instance), like Netflix, the overhead will be higher.

One challenge with using this method is deciding when it makes sense to use it. In the early days of developing an application, you usually don't encounter the problems this approach is trying to solve. Also, using this fine-grained, distributed architecture will slow down development. This is a serious problem for startups, as their biggest challenge is often how to rapidly develop their business model and related applications. Using a Y-axis split makes it harder to iterate quickly. But later, when the challenge becomes how to scale and you need to use functional decomposition to slice a monolithic application into a set of services , messy dependencies can make it difficult.

Another challenge is how to separate the system into microservices. It's a technical job, but some strategies may help. One way is to separate by verbs or use cases . For example, later you will see that the separated e-commerce application has a Shipping service that is responsible for dispatching completed orders. Another example of separation by verbs is a login service that implements the login use case.

Another method of separation is to separate systems by name or resource . This service is responsible for all operations on entities/resources of a given type. For example, later you will find out why e-commerce systems have an Inventory service to track whether a product is in stock or not.

In theory, each service should have only a small responsibility. Bob Martin (Uncle) talked about using the Single Responsibility Principle (SRP) to design classes. The SRP defines the responsibility of a class as a reason for change, and a class should have only one reason for change. It is also reasonable to use SRP to design services.

Another analogy that helps with service design is the way Unix utilities are designed. Unix provides numerous utilities such as grep, cat, and find. Each tool does one thing, usually very well, and can be combined with other tools to perform complex tasks using shell scripts.

Related Patterns

The monolithic architecture is an alternative model. The API Gateway pattern defines how clients can access services.

Known Cases

Most large scale web sites like Netflix , Amazon and eBay have transitioned from monolithic to microservices architecture.

Netflix is a very popular video streaming service that accounts for as much as 30% of Internet traffic, and it has a large-scale, service-based architecture. They handle more than 1 billion video streaming API requests per day from 800+ different types of devices. Each API can be expanded into an average of 6 calls to the backend service.

Amazon.com originally had a two-tier architecture. To scale, they migrated to a service-based architecture with hundreds of backend services. Applications that call these services include applications that implement the Amazon.com website and web service APIs. The Amazon.com web application calls 100-150 services to fetch data for building web pages.

Auction site ebay.com has also evolved from a monolithic architecture to a service-based architecture. The application layer contains multiple independent applications. Each application implements the business logic for a specific functional module (such as buying or selling). Each application uses the X-axis separation, and some applications, such as search, use the Z-axis separation. Ebay.com also uses the X, Y, Z combination scaling method for the database layer.