用于微服务编排的 AWS Kinesis

Question

我正在尝试使用 CQRS、DDD 和事件溯源概念为在线商店开发微服务。我将 AWS Kinesis 视为事件流。我认为这对精心设计的微服务很有好处。我有 2 项服务，客户数据服务和订购系统服务。我想查看每个客户的未付款订单总数和订单总数。因此，我应该将 orderCreated 事件和 orderPaid 事件发送到服务以获取客户数据，并重新计算相关客户的未付款订单总数和订单总数。

我可以将订购系统事件发送到 AWS Kinesis 并在客户的命令端服务中监听它吗？我应该将 AWS Kinesis 中的事件（orderCreated 和 orderPaid 事件）持久保存到客户命令端服务中的数据库吗？还是只更新客户查询端服务可以吗？我应该使用 AWS Lambda 作为事件处理器吗？你能给我一些关于这个模型的最佳实践吗？

提前致谢。

Answer 1

我将 AWS Kinesis 视为事件流。我认为这对精心设计的微服务很有好处。

我不认为 Kinesis 的用例是设计的；看到这个overview by Aditya Krishnan。或者这个以前的question on stack overflow。

我应该将事件（orderCreated 和 orderPaid 事件）从 AWS Kinesis 持久化到客户命令端服务中的数据库吗？

在我看来，问题在于：您真的不希望事件泄露给订阅者然后不会出现在记录簿中。因此，通常的顺序是将事件放入持久存储中，并且只有在您获得写入确认（这是“确认我们已达到最低持久性保证”的代理）之后，您才开始共享事件出去。

所以大多数设计都会颠倒您建议的顺序 - 首先是持久存储（数据库），然后是发布。但是您正在失去延迟；在商店结束之前，订阅者无法看到该事件。根据您的设计，您也许可以通过批量读取来弥补其中的一部分。

我们已经尝试过 SQS 和 SNS。但是，性能还不够好。发布和使用事件大约需要 5 秒。

嗯，考虑到我在 Kinesis 的建议中看到的内容，看起来您的胜率不会超过 order of magnitude；他们似乎在推荐完整的管道而不是快速管道。