我是微服务和事件溯源方面的新手，我试图找到一种在 AWS 上部署整个系统的方法。
据我所知，有两种方法可以实现事件驱动架构：
- 使用 AWS Kinesis Data Stream
- 使用 AWS SNS + SQS
因此，我的基本策略是将每个命令转换为存储在 DynamoDB 中的事件，并利用 DynamoDB 流向其他微服务通知新事件。但是怎么做呢？我应该使用前两种解决方案中的哪一种？
第一个具有以下优势：
- 消息排序
- 至少一次交付
但缺点是相当成问题的：
- 没有内置的自动缩放(可以使用触发器实现(
- 没有消息可见性功能(显然，要求确认(
- 无主题订阅
- 非常严格的读取事务：您可以使用多个分片来改进它 从我在这里读到的内容来看，您必须具有定义不明确的 lamda 数量，具有不同的调用优先级和未明确定义的策略，以避免在同一微服务的多个实例之间进行重复处理。
第二个具有以下优势：
- 完全托管
- 非常高的 TPS
- 主题订阅
- 消息可见性功能
缺点：
- SQS 消息是尽力排序，仍然不知道它们的含义。 它说"标准队列尽最大努力保留消息的顺序，但消息的多个副本可能会无序传递"。 这是否意味着，与邮件的副本相比，为邮件的 n 个副本提供第一个副本是按顺序传递的，而其他副本是无序传递的？或者"不止一个"可以是"全部"？
非常感谢各种建议！
I'm quite a newbe in microservices and Event-Sourcing
查看Greg Young的演讲Polygot Data，以更深入地了解以下内容。
跨服务边界共享事件有两种基本方法 - 推送模型和拉取模型。 对于关心事件排序的订阅者来说，拉取模型维护起来"更简单"。
基本思想是，每个订阅者跟踪自己的高水位标记，以了解它已处理的流中的事件数，并查询事件列表的有序表示形式以获取更新。
在 AWS 中，您通常可以通过查询权威服务以获取更新的事件列表(其实现可能包括分页(来获取此表示形式。 该服务可能会通过直接查询 dynamodb 或从 DynamoDB 获取最新密钥，然后在 S3 中查找事件的缓存表示形式来提供事件列表。
在这种方法中，被推出系统的"事件"实际上只是通知，允许订阅者减少写入 Dynamo 和他们自己的读取之间的延迟。
我通常会使用SNS(扇出(来广播通知。 需要簿记支持的消费者将使用 SQS。 但传达有序事件的主要通道是拉取。
我自己并没有认真研究过Kinesis——在前面的问题中有一些一般性的讨论——但我认为凯文·苏科切夫(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，但它不需要任何其他计费详细信息。