需要防御使用 CosmosDB 的事件溯源架构的古怪挑战

Question

在当前的计划中，传入的命令通过函数应用程序处理，导致事件被发送到事件中心，然后实现视图

有人认为，与其将事件存储在表存储中，并根据事件和快照物化视图，我们应该：

只需将事件流式传输到 Azure Monitor 中的日志即可进行审核

我们可以响应命令立即对域对象进行更改，并将更改提要用作物化视图的事件源。

他甚至没有看到物化视图的优势。为什么不直接使用查询？争论是我们预计不会有很多流量。

他想通过将事件保存到 azure 监视器日志来完成整个审计日志 - 只是一个应用程序日志。相反，这些命令应该直接修改 Cosmos 中实体的表示，我们将使用来自 CosmosDB 的更改提要作为我们的域对象事件，或者我们将通过该流的订阅者创建新事件。

这实际上是一种有利的方法吗？你能想出我们不想这样做的任何理由吗？似乎我们会在这里失去一些东西。

他是说我们不再需要关心最终的一致性，因为我们会立即保持一致性。

我评估过的每个参考实现都没有按照他的建议去做。我对事件溯源/CQRS 范式的优点/缺点并不深入了解，所以我现在不知所措..目前正在疯狂研究

这是一个概念问题，因此没有太多代码示例。但是，这里有一些参考资料似乎支持我正在采取的方法。

https://medium.com/@thomasweiss_io/planet-scale-event-sourcing-with-azure-cosmos-db-48a557757c8d

https://sajeetharan.com/2019/02/03/event-sourcing-with-azure-eventhub-and-cosmosdb/

https://docs.microsoft.com/en-us/azure/architecture/patterns/event-sourcing

Answer 1

如果您的目标只是拥有审核日志，那么基于状态的持久性可能是一个不错的选择。事件溯源给实现方面增加了一些复杂性，除非您能够确定使用它的更多优势，否则您可能无法说服您的团队将这种复杂性引入系统。关于事件溯源的优点和缺点，SO 以及一些博客文章中有很多问题和答案，因此我不会在这里进行讨论。

不过，我可以警告您，您列表中的第二篇文章非常薄弱，很可能会给您带来许多困难。事件中心的作用完全不清楚，它没有解释任何有关投影和读取模型（您所说的“物化视图”）的信息。只有非常有限的用例可以仅通过 id 获取一个实体，并且无法跨多个实体执行查询。这也可能回答了您对读取模型的担忧。当您第一次开始弄清楚如何根据某些条件（查询）获取实体列表时，您很快就会需要它们。

如果您可以管理所涉及的成本，那么使用 CosmosDb 作为事件存储是完全可行的，如第一篇文章中所述。请记住将更改源 TTL 设置为 -1，否则，您将无法在需要时重播投影。

总结一下：

• 保留审计日志可以在没有事件溯源的情况下完成，但您需要确保事件可靠地发布，最好是在与实体状态更新相同的事务中。这通常很困难或不可能，但您可能会接受审核要求不严格的风险。您还可以将审核日志基于 CosmosDb 更改源，仅收集文档更改并将其记录在某处。
• 事件溯源是一种强大的技术，但它既有优点也有缺点。对使用事件源最常见的偏见是其实现复杂性。如果您的团队在构建事件溯源系统方面有一定经验，那么这可能不是一个大问题。如果你没有这样的团队，你可能想建立一个小规模的尖峰来获得一些经验。
• 如果您没有获得团队的完全支持来使用事件溯源，那么一旦出现任何问题，您将受到所有指责。在某些时候它会出错，尤其是在这方面经验很少的情况下。
• 在投入生产之前，花一些时间阅读书籍并亲自尝试一些东西。
• 请勿将事件中心用于任何其设计目的之外的用途。事件中心是功能强大的事件摄取传输，具有有限的 TTL，应该用于此目的。
• 不要使用表存储作为事件存储，除非您仅按 id 读取实体。我在生产中使用它来处理这样的场景，并且它有效（在某种程度上），但您无法从那里投影读取模型。