本站点由 Chris Richardson 编写和维护，他是经典技术著作《POJOS IN ACTION》一书的作者，也是 cloudfoundry.com 最初的创始人。Chris 的研究领域包括 Spring、Scala、微服务架构设计、领域驱动设计、NoSQL 数据库、分布式数据管理、事件驱动的应用编程等。Chris 是一位连续创业者，eventuate.io 是他的最新创业项目，一个微服务应用和数据服务平台。
Chris 定期为企业提供微服务设计培训和实战项目的架构咨询服务。近年来 Chris 多次访问中国，为包括华为、SAP、惠普、东风汽车等大型企业提供微服务架构相关的技术咨询服务。如您希望与 Chris 深入交流，建立合作，请点击下方按钮跟他取得联系。
加入 微服务架构的 Google 讨论组（需要翻墙）
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
However, for a variety of reasons distributed transactions are not a viable choice for most modern applications.
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.
This pattern has the following benefits:
This solution has the following drawbacks:
There are also the following issues to address:
An e-commerce application that uses this approach would work as follows:
Order Servicecreates an Order in a pending state and publishes an
Customer Servicereceives the event and attempts to reserve credit for that Order. It then publishes either a
Credit Reservedevent or a
Order Servicereceives the event from the
Customer Serviceand changes the state of the order to either approved or cancelled
The article Event-Driven Data Management for Microservices by @crichardson describes this pattern