AWS事件采购实施

Question

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

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

• 使用AWS运动数据流

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

第一个具有以下优点：

• 消息排序

但缺点很成问题：

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

第二种方法具有以下优点：

• 完全管理
• 非常高的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非常适合一个非常特殊的用例，如果你的应用程序不适合这个用例，那么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，但不需要任何其他账单详细信息。）