CQRS + EventSourcing 可扩展性

Question

我正在尝试在我的新项目中使用 CQRS 和 EventSorcing。我遵循 Greg Young 几年前建议的方式（Mark Nijhof 实施 - http://cre8ivethought.com/blog/2009/11/12/cqrs--la-greg-young/）。我有一些关于这个解决方案的可扩展性的问题。

Mark Nijhof 的 this 文章中提到了一些要点。但现在的问题是 Denormalizer 部分，它负责更新报告数据库。这部分我想做异步，所以在将事件发布到总线后我想立即返回控制。我们建议可以将 Denormalizer 实现为独立的 Web 服务 (WCF)，它将处理传入事件并使用批量命令以定时方式更新报告数据库。看起来它可能是一个瓶颈，所以我们还想在这一点上添加一些可扩展性 - 一个集群解决方案。但是在集群的情况下，我们无法控制报告数据库更新的顺序（或者我们应该实现一些奇怪的，我猜有错误的逻辑会检查报告数据库中的对象版本）。另一个问题是解决方案的可持续性：如果失败，我们将在非规范化器中丢失更新，只要我们不在任何地方持久化它们）。所以现在我正在寻找这个问题的解决方案（Denormalizer 可扩展性），欢迎提出任何想法！

Answer 1

首先，您肯定希望将非规范化器托管在一个单独的进程中。从那里，您可以让域将域中发生的事件发布到您的消息传递基础架构。帮助加速非规范化的一种简单策略是按消息/事件类型将事物分开。换句话说，您可以为每种消息类型创建一个单独的队列，然后让非规范化程序订阅（使用消息总线）相应的事件。这样做的好处是您不会让消息一个接一个地堆积起来——一切都开始并行运行。唯一可能存在争用的地方是在侦听多种类型的表上。即便如此，您现在已经在许多端点之间分配了负载。

只要您使用某种消息传递基础架构，您就不会在尝试非规范化时丢失事件消息。相反，在一定次数的失败重试后，该消息将被视为“毒药”并移至错误队列。只需监视错误队列中的问题。消息进入错误队列后，您可以检查日志以了解其存在的原因、解决问题，然后将其移回。

另一个考虑因素是 Mark Nijhof 的例子有些陈旧。 DDD/CQRS Google Group 中有许多可用的 CQRS 框架以及大量建议。