张瑞峰的博客

导航

微服务事件驱动 VS saga模型

起因

搜索microservice event driven,出来microservices.io的网页,很专业。

打开Event-driven architecture,提示该技术已被弃用,且被Saga pattern 替代。

Event-driven architecture

问题

这是由微服务架构引发的一个trade-off。你采用了微服务架构,微服务架构要求每个服务都有自己的数据库(Databases per Services pattern),导致我们不能用以前的ACID事务来对2个微服务的不同数据库进行事务管理。

解决方案

用事件驱动及最终一致的方法。每个服务只要update数据就发布事件,其他服务订阅事件。当一个事件被一个服务接收时,那个服务更新其数据。

处理敏感数据时

当我们处理销售事务时,我们知道这些数据非常重要。所以这些处理这些数据必须100%正确。

为了达到这准确度,我们系统必须不遗漏任何事件消息。为此,我们应用outbox pattern。

什么是outbox pattern?简单地说,当你的API发布事件消息时,它不直接发送消息,而是先把消息持久化到数据库表中。然后用一个计划任务在指定时间间隔发送渐增消息。

步骤:

  1. 业务模块发布事件
  2. 事件服务持久化消息到数据库
  3. 计划任务服务触发“发送事件消息”任务
  4. 事件服务查询渐增事件消息
  5. 事件服务通过RabbitMQ发布消息

益处:

  1. 事件消息先持久化到数据库,ACID事务属性保证了它的持久性。
  2. 当一个事件丢失,那个消息能从数据库中查出。
  3. 一个丢失的事件可以有效地从数据库中恢复过来。

坏处:

  1. 增加了复杂性
  2. 发布事件有延迟
  3. 发布基本事件,至少需要2个技术:存储系统和消息队列协议。

Saga pattern

问题:

同上

解决方案

将跨服务的业务性事务实现为saga。一个saga是一系列本地事务。每个本地事务update数据库并发布一个消息或者事件来触发下一个saga中的本地事务。如果一个本地事务因违反业务准则失败,则saga执行一系列事务来进行修正,回滚之前本地事务做的修改。

posted on 2020-03-28 21:42  张瑞峰的博客  阅读(583)  评论(0编辑  收藏  举报