Chris Richardson 的微服务架构网站

本站由 Kong 提供支持

微服务架构咨询和培训服务

本站点由 Chris Richardson 编写和维护，他是经典技术著作《POJOS IN ACTION》一书的作者，也是 cloudfoundry.com 最初的创始人。Chris 的研究领域包括 Spring、Scala、微服务架构设计、领域驱动设计、NoSQL 数据库、分布式数据管理、事件驱动的应用编程等。Chris 是一位连续创业者，eventuate.io 是他的最新创业项目，一个微服务应用和数据服务平台。

Chris 定期为企业提供微服务设计培训和实战项目的架构咨询服务。近年来 Chris 多次访问中国，为包括华为、SAP、惠普、东风汽车等大型企业提供微服务架构相关的技术咨询服务。如您希望与 Chris 深入交流，建立合作，请点击下方按钮跟他取得联系。

预约课程

微服务应用的示例代码

为了避免纸上谈兵，Chris 提供了一套与这些模式相关的示例代码。这组代码使用 eventuate 框架，实现了微服务架构下分布式数据的存取。请点击下方按钮访问。

访问代码

模式库

核心模式

服务拆分

部署模式

需要关注的边界问题

通讯模式

数据管理

安全模式

可测试性

可观测性

UI 模式

订阅微服务邮件列表

全新的微服务应用支撑平台，成功解决微服务架构下分布式数据管理的难题。

了解更多

加入 微服务架构的 Google 讨论组（需要翻墙）

Pattern: Event-driven architecture

Problem

You have applied the Database per Service pattern. Each service has its own database. Some business transactions, however, span multiple service so you need a mechanism to ensure data consistency across services.

For example, lets imagine that you are building an e-commerce store where customers have a credit limit. The application must ensure that a new order will not exceed the customer’s credit limit. Since Orders and Customers are in different databases the application cannot simply use a local ACID transaction. In theory, it could use a distributed transaction that spans the Customer Service and the Order Service. However, for a variety of reasons distributed transactions are not a viable choice for most modern applications.

Solution

Use an event-driven, eventually consistent approach. Each service publishes an event whenever it update its data. Other service subscribe to events. When an event is received, a service updates its data.

Resulting context

This pattern has the following benefits:

  • It enables an application to maintain data consistency across multiple services without using distributed transactions

This solution has the following drawbacks:

  • The programming model is more complex

There are also the following issues to address:

  • In order to be reliable, an application must atomically update its database and publish an event. It cannot use the traditional mechanism of a distributed transaction that spans the database and the message broker. Instead, it must use one the patterns listed below.

Example

An e-commerce application that uses this approach would work as follows:

  1. The Order Service creates an Order in a pending state and publishes an OrderCreated event.
  2. The Customer Service receives the event and attempts to reserve credit for that Order. It then publishes either a Credit Reserved event or a CreditLimitExceeded event.
  3. The Order Service receives the event from the Customer Service and changes the state of the order to either approved or cancelled

See also

The article Event-Driven Data Management for Microservices by @crichardson describes this pattern

Tweet
© 2017 Chris Richardson 版权所有 • 保留一切权利 • 本站由 Kong 提供支持.