amazon-web-services - AWS 事件溯源实现

标签 amazon-web-services microservices event-sourcing event-driven

我是微服务和事件溯源方面的新手,我正试图找出一种在 AWS 上部署整个系统的方法。

据我所知,实现事件驱动架构有两种方法:

  • 使用 AWS Kinesis Data Stream
  • 使用 AWS SNS + SQS

所以我的基本策略是将每个命令转换为存储在 DynamoDB 中的事件,并利用 DynamoDB Streams 通知其他微服务有关新事件的信息。但是怎么做?我应该使用前两种解决方案中的哪一种?

第一个有以下优点:

  • 消息排序
  • 至少一次交货

但是缺点还是挺成问题的:

  • 没有内置的自动缩放功能(您可以使用触发器来实现)
  • 没有消息可见性功能(显然是要求确认)
  • 没有主题订阅
  • 非常严格的读取事务:您可以使用我阅读的 here 中的多个分片来改进它您必须有一个未明确定义的具有不同调用优先级的 lamdas 数量和一个未明确定义的策略,以避免跨同一微服务的多个实例进行重复处理。

第二个的优点是:

  • 完全托管
  • 非常高的 TPS
  • 主题订阅
  • 消息可见性功能

缺点:

  • SQS 消息是尽力排序的,但仍然不知道它们的含义。 它说“标准队列尽最大努力保持消息的顺序,但消息的多个副本可能会乱序传递”。 这是否意味着给消息的 n 个副本,与其他消息的副本相比,第一个副本是按顺序传递的,而其他副本是无序传递的?或者“更多”可能是“全部”?

非常感谢您的各种建议!

最佳答案

I'm quite a newbe in microservices and Event-Sourcing

回顾 Greg Young 的演讲 Polygot Data以更深入地了解接下来的内容。

跨服务边界共享事件有两种基本方法 - 推送模型和拉取模型。对于关心事件顺序的订阅者,拉模型更易于维护。

基本思想是每个订阅者跟踪自己的高水位标记以了解其已处理的流中的事件数量,并查询事件列表的有序表示以获取更新。

在 AWS 中,您通常会通过向权威服务查询更新的事件列表(其实现可能包括分页)来获取此表示。该服务可能通过直接查询 dynamodb 或通过从 DynamoDB 获取最新 key ,然后在 S3 中查找事件的缓存表示来提供事件列表。

在这种方法中,被推出系统的“事件”实际上只是通知,允许订阅者减少写入 Dynamo 和他们自己读取之间的延迟

我通常会使用 SNS(扇出)来广播通知。需要记账支持以处理已处理的通知的消费者将使用 SQS。但是传递有序事件的主要 channel 是拉。

我自己并没有仔细研究 Kinesis - 有一些 general discussion in earlier questions ——但我认为 Kevin Sookocheff 在写作时会有所收获

...if you dig a little deeper you will find that Kinesis is well suited for a very particular use case, and if your application doesn’t fit this use case, Kinesis may be a lot more trouble than it’s worth.

Kinesis’ primary use case is collecting, storing and processing real-time continuous data streams. Data streams are data that are generated continuously by thousands of data sources, which typically send in the data records simultaneously, and in small sizes (order of Kilobytes).

Another thing: the fact that I'm accessing data from another 
microservice stream is an anti-pattern, isn't it?

嗯,将系统划分为微服务的部分目的是减少系统功能之间的耦合。跨微服务边界访问数据会增加耦合。所以那里有些紧张。

But basically if I'm using a pull model I need to read 
data from other microservices' stream. Is it avoidable?

如果您查询所需信息的服务,而不是自己将其从流中挖掘出来,则可以减少耦合——就像向服务请求数据而不是访问 RDBMS 并自己查询表一样。

如果您可以完全避免在服务之间共享信息,那么耦合度会更低。

(简单示例:订单履行需要知道订单何时已付款;因此在付款时它需要一个相关性 id,但它不需要任何其他计费详细信息。)

关于amazon-web-services - AWS 事件溯源实现,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/52632129/

相关文章:

database - 微服务认证/授权架构

go - 未实现的 desc = 未知服务 pb.AuthService 我的简单例份验证服务器上出现错误

docker - 为什么不存在的镜像在Kubernetes部署中起作用

asynchronous - 事件溯源:我什么时候(而不是)应该使用 Message Queue?

EventSourcing 和 DDD 实体事件

node.js - 从服务器重定向时,页面从 HTTPS 重定向到 HTTP

amazon-web-services - 如何使用 pulumi aws provider 定义默认标签

python - 使用 CFLAGS 和 PIP 缩小 AWS Lambda 部署包以适应 sklearn

c# - 请求的版本错误 AWS Simple Notification Service .NET SDK

domain-driven-design - 如何使用 DDD/CQRS/ES 为仓库应用程序建模?