AWS Event-Sourcing实施

Question

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

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

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

第一个优点是：

但是缺点非常成问题：

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

第二个优点是：

缺点：

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进行过认真的研究- 在前面的问题中进行了一些一般性的讨论 -但我认为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，但不需要任何其他账单明细。）