微服务事件驱动 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执行一系列事务来进行修正，回滚之前本地事务做的修改。