AWS Event-Sourcing实施

Question

我是微服务和事件采购的新手，我试图想出一种在AWS上部署整个系统的方法。

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

• 使用AWS Kinesis数据流
• 使用AWS SNS + SQS

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

第一个具有以下优点：

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

但缺点很成问题：

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

第二个具有以下优点：

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

缺点：

• SQS消息是尽力排序，但仍不知道它们的含义。它说“标准队列尽最大努力保留消息的顺序，但是消息的多个副本可能无序传递”。这是否意味着提供n份邮件的第一份副本按顺序发送，而其他邮件与其他邮件的副本相比无序交付？或者“更多那个”可能是“全部”？

非常感谢各种建议！

Answer 1

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

回顾Greg Young的演讲Polygot Data，了解更多有关后续内容的信息。

跨服务边界共享事件有两种基本方法 - 推模型和拉模型。对于关心事件排序的订阅者来说，拉模型“维护起来更简单”。

基本思想是每个订户跟踪其自己的高水位标记，表示其处理的流中有多少事件，并查询事件列表的有序表示以获得更新。

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

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

我通常会在广播通知中找到SNS（扇出）。需要簿记支持的消费者会使用SQS来处理他们所处理的通知。但是，传递有序事件的主要渠道是拉动。

我自己也没有看过Kinesis - 有一些general discussion in earlier questions - 但我认为Kevin Sookocheff写的东西

...如果你深入挖掘，你会发现Kinesis非常适合一个非常特殊的用例，如果你的应用程序不适合这个用例，Kinesis可能会比它的价值更麻烦。

Kinesis的主要用例是收集，存储和处理实时连续数据流。数据流是由数千个数据源连续生成的数据，这些数据源通常同时发送数据记录，并以小尺寸（千字节的顺序）发送。

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，但它不需要任何其他结算明细。）