Amazon s3 微服务&x2B；CQRS实现

我正在使用CQRS模式实现一个微服务架构。我有一个使用API网关、Lambda和DynamoDB的工作实现，只有一个例外——事件源

事件源使应用程序向平台中的其他服务可以使用的事件流发布通知。此通知表示作为原始HTTP请求的一部分发生的事件。例如，如果用户使用一个完整的“将患者检查到医院”模型发布HTTP POST，那么Lambda会将其分解并按顺序发布多个事件

患者登记（包括患者Id、医院Id+就诊Id）

指定的房间（包括房间号+就诊id）

患者测试（包括测试+就诊id）

患者已出院（就诊id）

此模式的目的是提供患者住院期间发生的所有事件的审计跟踪。这个示例（不是我实际构建的）将存储在事件源中，可以随时重播。如果在所有服务中删除了VisitId，我们可以一次按顺序重播一个事件，并复制原始记录的精确副本。你认为所有的记录都是不可变的。每个POST都将推入事件源，然后进入数据库，该数据库将在HTTP GET请求期间拉出数据。它还将有订阅者，他们将获取这些数据的一部分并做其他事情，例如“访问调查”服务，该服务将听取患者的退房事件并准备术后调查

我已经研究了几个AWS服务来提供这一点。我了解Kinesis数据流，但我不喜欢定价结构，也不想处理碎片（无自动缩放）。由于我的整个平台是建立在基于消费的定价（Dynamo、Lambda等）基础上的，因此我希望以相同的方式保留我的事件源。这使得我更容易估计每个用户的成本，因为我只是根据每个用户每月的估计请求进行计算

我一直在为流本身使用SNS，提供通知，这非常棒。超级快速，开发时没有任何重大问题。但问题是，这不适合仅用于重播存储的事件消息传递。对于一家重播店，我认为Kinesis Firehose很有意义。。。同时发送给S3+SNS。事实证明SNS不是一个可用的交付目的地。我可以自己放进S3，然后发布到SNS，但这看起来像是代码库中的重复工作，当我可以设置一个S3触发器来触发一个Lambda，然后有另一个小Lambda对S3中的事件登录做出反应，并插入到DynamoDB中。我发现这比仅仅通过SNS发布要慢得多。我也不确定Put事件的重试策略。这简化了重试，因为我可以重复使用触发Lambda中的代码来重播bucket路径中的所有事件

我可以把对象放到同一个HTTP POST Lambda中，然后发布到SNS。如果SNS发布失败，那么我现在在S3中有一个从未发布过的对象。我必须编写一个不同的Lambda来处理修复和发布。不是世界末日——不管怎样，我都有两个lambda要部署。我只是不确定在AWS服务的这种模式中，哪种方式更有意义

有人做过类似的事情吗？有什么建议吗？我是否正在努力进入一个以后很难管理的技术漏洞？如果我能坚持以消费为基础的定价模式，我也愿意选择其他途径。谢谢

事件源使应用程序向平台中的其他服务可以使用的事件流发布通知

在这里您需要稍微小心一点——至少有两种不同的“事件源”定义

如果你关心事件来源，在通常与CQR（Greg Young等）结合的意义上，那么你的事件就是你的记录。这带来的一个重要的复杂性是，在对“事件流”进行更改时，您的服务需要能够锁定该“事件流”（没有该锁定，您会遇到“丢失编辑”的情况，并且必须清理混乱）

因此，“指向当前更改的指针”需要存在于具有事务的对象中。DynamoDB应该可以胜任这项工作（根据我对2017年Invent2017年展会的活动采购突破室的记忆）。理论上，您可以在dynamo中使用锁，它包含指向存储在S3中的不可变文档的指针。我还没能说服自己，权衡是合理的复杂性，但尽我所能，在这个架构中没有任何东西违反物理和因果关系

如果您的运营团队对Dynamo不满意，另一个合理的选择是RDS；选择您首选的关系数据引擎，向其部署事件存储模式，然后开始

至于酒吧子部分，我相信你在SNS上走的是对的。它是从一个出版商向多个消费者“散播”消息的正确选择。是的，它不支持重播，但这很好——重播可以通过从记录簿中提取事件来实现。见格雷格·杨的后半部分。是的，有时你会在推送频道和拉送频道上都收到消息，但这没关系；当您认为分布式体系结构是一个好主意时，您已经注册了幂等消息处理

编辑 为什么需要在DynamoDB中存储指针

因为S3不提供任何锁定；这意味着，在不愉快的路径上，两个逻辑副本试图写入不同版本的数据，最终成为丢失编辑问题的受害者

您可以使用乐观锁定来管理这种情况——类似于HTTP的条件PUT；但是S3（上次我检查时）不支持条件mo