本站点由 Chris Richardson 编写和维护，他是经典技术著作《POJOS IN ACTION》一书的作者，也是 cloudfoundry.com 最初的创始人。Chris 的研究领域包括 Spring、Scala、微服务架构设计、领域驱动设计、NoSQL 数据库、分布式数据管理、事件驱动的应用编程等。Chris 是一位连续创业者，eventuate.io 是他的最新创业项目，一个微服务应用和数据服务平台。
Chris 定期为企业提供微服务设计培训和实战项目的架构咨询服务。近年来 Chris 多次访问中国，为包括华为、SAP、惠普、东风汽车等大型企业提供微服务架构相关的技术咨询服务。如您希望与 Chris 深入交流，建立合作，请点击下方按钮跟他取得联系。
加入 微服务架构的 Google 讨论组（需要翻墙）
You have applied the Event-driven architecture pattern. In order to be reliable, services must atomically publish events whenever their state changes. It is not viable to use a distributed transaction that spans the database and the message broker. How to reliably/atomically publish events whenever state changes?
A good solution to this problem is to use event sourcing. Event sourcing persists the state of a business entity such an Order or a Customer as a sequence of state-changing events. Whenever the state of a business entity changes, a new event is appended to the list of events. Since saving an event is a single operation, it is inherently atomic. The application reconstructs an entity’s current state by replaying the events.
Applications persist events in an event store, which is a database of events. The store has an API for adding and retrieving an entity’s events. The event store also behaves like a message broker. It provides an API that enables services to subscribe to events. When a service saves an event in the event store, it is delivered to all interested subscribers.
The following diagram shows how the e-commerce system could use event sourcing to persist orders.
Instead of simply storing the current state of each order as a row in an
ORDERS table, the application persists each Order as a sequence of events.
CustomerService can subscribe to the order events and update its own state.
Event sourcing has several benefits:
Event sourcing also has several drawbacks: