microservices - 需要使用/Cosmos DB 抵御对事件溯源架构的古怪挑战

Question

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

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

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

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

他甚至没有看到物化 View 的好处。为什么不直接使用查询？争论是我们不希望有很多流量。

他想通过将事件保存到 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 以及一些博客文章中有许多关于事件溯源的优缺点的问题和答案，因此我不会在这里进行讨论。

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

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

总结一下:

保留审计日志可以在没有事件溯源的情况下完成，但您需要确保事件被可靠地发布，最好在与实体状态更新相同的事务中。这通常很难或不可能，但您可能会接受审计要求不严格的风险。您还可以将审核日志基于 CosmosDb 更改提要，只需收集文档更改并将其记录在某处即可。

事件溯源是一种强大的技术，但它有利有弊。对使用事件溯源的最常见偏见是其实现的复杂性。如果您的团队在构建事件源系统方面有一定的经验，这可能不是什么大问题。如果你没有这样的团队，你可能想建立一个小规模的秒杀来获得一些经验。

如果您没有得到团队的完全支持来使用事件溯源，那么如果出现任何问题，您将承担所有责任。它会在某个时候出错，尤其是在这方面经验不足的情况下。

在投入生产之前，花一些时间阅读书籍并自己尝试一下。

不要将事件中心用于任何非设计用途。事件中心是具有有限 TTL 的强大事件摄取传输，它应该用于此目的。

不要使用 Table Storage 作为事件存储，除非你只通过 id 读取实体。我在生产中使用它来处理这样的场景并且它(在某种程度上)起作用了，但是你不能从那里投影读取模型。