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

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

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

预约课程

微服务应用的示例代码

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

访问代码


模式库

核心模式

服务拆分

部署模式

需要关注的边界问题

通讯模式

数据管理

安全模式

可测试性

可观测性

UI 模式


订阅微服务邮件列表

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

了解更多

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

Pattern: Event sourcing

Problem

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?

Solution

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.

Example

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. The CustomerService can subscribe to the order events and update its own state.

For more details, see the Eventuate Platform, which is an application platform based on event sourcing and CQRS. There are several example applications

Resulting context

Event sourcing has several benefits:

  • It solves one of the key problems in implementing an event-driven architecture and makes it possible to reliably publish events whenever state changes.
  • Because it persists events rather than domain objects, it mostly avoids the object‑relational impedance mismatch problem.
  • It provides a 100% reliable audit log of the changes made to a business entity
  • It makes it possible to implement temporal queries that determine the state of an entity at any point in time.
  • Event sourcing-based business logic consists of loosely coupled business entities that exchange events. This makes it a lot easier to migrate from a monolithic application to a microservice architecture.

Event sourcing also has several drawbacks:

  • It is a different and unfamiliar style of programming and so there is a learning curve.
  • The event store is difficult to query since it requires typical queries to reconstruct the state of the business entities. That is likely to be complex and inefficient. As a result, the application must use Command Query Responsibility Segregation (CQRS) to implement queries. This in turn means that applications must handle eventually consistent data.

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