【发布时间】:2018-04-28 22:39:14
【问题描述】:
我有一个在 AWS Lambda 上运行的基于微服务的应用程序。其中两个最关键的微服务使用事件溯源/cqrs。
背景:(这也是我整理思路)
我正在使用 this library 并将事件存储在 DynamoDB 中,并将预测存储在 AWS S3 中。
写入部分的工作原理很像:每个命令调用都会从 DynamoDB 加载聚合的当前状态(通过处理程序运行事件和/或加载缓存的聚合),它会根据某些情况决定接受或拒绝命令业务逻辑,然后使用 KeyConditionExpression: 'aggregateId = :a AND version >= :v' 写入 DynamoDB,其中版本是为该聚合处理的事件计数。如果存在冲突,则写入失败。对我来说似乎是一个很好的系统!
然后将每个事件广播到 SNS(主题名称是服务名称),以便其他服务可以根据需要对事件做出反应。
我真正挣扎的部分是阅读。投影存储在 S3 中,并使用为每个事件源处理的最后一个 commitId 进行标记。当读取查询进入时,它会从 S3 (对于所有聚合) 加载整个投影状态,查询所有较新事件的事件源,计算最新状态(同样,对于所有聚合 - 并写入S3 更新的对象),并根据查询参数返回状态的相关部分。
我的问题:(或其中之一)
我认为我做错了预测。
我的大多数预测仅按重要属性对 id 进行分组,因此文件保持相对较小。但我还需要一种方法来检索单个聚合。为此使用投影似乎很疯狂,因为我需要每次加载整个状态(即每个投影聚合)应用新事件,然后检索我想要的记录(它甚至可能没有改变)。
这就是我现在正在做的事情,它的表现很好(
另一个问题是查询。我需要为我需要查询的每个属性建立一个投影映射值来匹配聚合ID!一定有更好的方法!
无论我如何看待这个问题,预测总是需要整个当前状态 + 任何新事件才能返回甚至没有更改的单个记录。
【问题讨论】:
标签: domain-driven-design microservices cqrs event-sourcing