AWS Event-Sourcing实施

Question

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

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

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

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

第一个具有以下优点：

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

但是缺点很成问题：

• 没有内置的自动缩放功能（您可以使用触发器来实现）
• 没有消息可见性功能（显然是要求确认）
• 没有主题订阅
• 非常严格的读取事务：您可以使用我阅读的here中的多个分片来改进它，您必须具有数量不明确的，具有不同调用优先级的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和读取自己的内容之间的 latency 。

我通常会联系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并查询表一样。< / p>

如果您完全可以避免在服务之间共享信息，那么耦合就更少了。

（朴素的示例：订单履行需要知道何时支付订单；因此在付款时需要相关ID ，但不需要任何其他计费详细信息。）