使用 AWS Lambda 更新无服务器 CQRS + EventSourcing ReadModel答案

【问题标题】：Serverless CQRS + EventSourcing ReadModel update with AWS Lambda使用 AWS Lambda 更新无服务器 CQRS + EventSourcing ReadModel
【发布时间】：2018-02-19 18:39:52
【问题描述】：

我正在尝试基于 AWS 无服务器架构实现 CQRS + 事件溯源后端。问题在于 readmodel 更新。

当事件保存到事件存储时，它会发布到 SNS。 SNS 然后调用UpdateReadModel lambda。当多个顺序事件发布到 SNS 时，会调用多个 lambda。

第一个问题是它们都执行相同的 ReadModel 更新，实际上只有一个 lambda 必须为所有事件调用。

第二个问题是，在多次执行 lambdas 后，最终的 ReadModel 状态可能会损坏。

要求每个 ReadModel 只调用一个 lambda。

可能的解决方案：

使用 MessageBroker（RabbitMQ 或 Kafka）+EC2 实例调用UpdateReadModelLambda。
在 SNS + EC2 实例之后添加 SQS，并编写调用 lambdas 并从 SQS 获取事件的代码。

但我不想使用实例，因为它不适合无服务器方法，开发人员应该手动管理和扩展容器或 MessageBus。

也许有人已经解决了这个问题，或者有其他云服务 + CQRS + EventSourcing 的解决方案？

【问题讨论】：

自己没试过，但看起来这个东西正在做你需要的事情：github.com/doodeck/aws-lambda-idempotent
我们正在开发一个通过 API 提供 EventSourcing 和 CQRS 的云托管事件引擎。它处于超早期阶段，但如果您愿意，可以免费试用 :-) serialized.io
Kinesis Streams 是否可以替代 SNS？和/或带有分区键 (=stream id) 和排序键 (=sequence number) 的 DynamoDB 似乎是一个很好的潜在事件存储，并且可以与 lambda 或 kinesis 很好地集成。

标签： amazon-web-services aws-lambda cqrs event-sourcing serverless-architecture

【解决方案1】：

使用消息代理进行预测通常不是一个好主意。你不能保证排序，你不能保证只交付一次，你不能只为一个读取模型重放事件，因为其他读取模型将再次获得相同的事件，你不能拥有事件驱动的系统，因为在重放时它们也会获得集成事件。我不会那样做。

您可以使用由事件存储操作（例如 Dynamo 插入）触发的 lambda 函数。每个 lambda 可以是一种聚合类型的投影集合，也可以是一个单一的投影。不过，请记住，如果您重试，您有可能会出现乱序的事件，我非常不确定您是否可以在那里禁用并行化。

【讨论】：