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

生产环境的部署复杂度。对于包含多种不同服务类型的系统，部署和管理的操作复杂度仍然存在。
内存消耗增加。微服务架构使用 NxM个服务实例来替代N个一体应用实例。如果每个服务运行在自己独立的JVM(或类似)上，通常有必要对实例进行隔离，对这么多运行的JVN，就有M倍的开销。另外，如果每个服务运行在独立的VM(如EC2实例)，如Netflix，开销会更高。

使用该方法的一个挑战就是决定何时使用才合理。在开发应用的初期，你通常不会遇到这种方法试图解决的问题。而且，使用这个精细、分布式的架构将会拖慢开发进度。对初创公司，这是个严重问题，因为它们的最大挑战通常是如何快速发展业务模型及相关应用。使用Y轴切分使快速迭代更加困难。但是之后，当挑战变成如何伸缩，你需要使用功能分解将一体应用切分为一组服务时，混乱的依赖关系可能使之变得困难。

另一个挑战是如何将系统分隔为微服务。这是个技术活，但有些策略可能有帮助。一种方法是通过动词或用例来分隔。比如，之后你将看到分隔后的电子商务应用有个负责派送已完成订单的Shipping服务。另一个通过动词分隔的例子是实现登录用例的登录服务。

另一种分隔方法是通过名称或资源来分隔系统。这种服务负责对给定类型的实体/资源的所有操作。比如，之后你会发现为何电子商务系统有个Inventory服务来跟踪产品是否在库存中。

理论上，每个服务应该只承担很小的职责。Bob Martin(大叔)讲过使用单一职责原则(SRP)来设计类。SRP定义类的职责作为变化的原因，而且类应该只有一个变化的原因。使用SRP来设计服务也是合理的。

另一个有助于服务设计的类比是Unix实用工具的设计方法。Unix提供大量的实用工具如grep、cat和find。每个工具只做一件事，通常做得非常好，并且可以跟其他工具使用shell脚本组合来执行复杂任务。

已知案例

大多数大规模的web站点，如 Netflix, Amazon和eBay都从一体架构转变为微服务架构。

Netflix是个非常受欢迎的视频流服务提供商，占有多达30%的互联网流量，它有着大规模、基于服务的架构。他们每天处理800+不同类型设备超过10亿次视频流API的请求。每个API可以展开成平均6次对后端服务的调用。

Amazon.com 原有个两层架构。为了伸缩，他们迁移到一个包含上百个后端服务的基于服务的架构。调用这些服务的应用中包括实现Amazon.com网站和web service API的应用。Amazon.com网站应用调用100-150个服务来获取数据用于构建网页。

拍卖网站ebay.com也从一体架构发展成基于服务的架构。应用层包含多个独立的应用。每个应用实现特定功能模块(如购买或销售)的业务逻辑。每个应用使用X轴的分隔，有些应用如搜索，使用Z轴分隔。Ebay.com也对数据库层采用X,Y,Z的组合伸缩方式。

变更

注：[1] 双披萨团队(two-pizza team)：两个披萨就可以喂饱整个团队，指团队规模很小。

第一篇：一体化架构(Monolithic Architecture)

第二篇：微服务架构(Microservices Architecure)

伸缩立方(Scale Cube)

第三篇：API网关(API Gateway)

http://my.oschina.net/douxingxiang/blog/357425

[Translation] Microservices Architecture