Voi*_*ice 6 .net architecture asp.net cqrs event-sourcing
我正在尝试在我的新项目中使用CQRS和EventSorcing.我跟随Greg Young几年前提出的方式(Mark Nijhof实施 - http://cre8ivethought.com/blog/2009/11/12/cqrs--la-greg-young/).我有一些与此解决方案的可扩展性有关的问题.
一些点被提到这个文章由Mark Nijhof.但现在的问题是Denormalizer部分,它负责更新报告数据库.这部分我想要异步,所以在将事件发布到总线后我想立即返回控件.我们建议将Denormalizer实现为独立的Web服务(WCF),它将处理传入的事件并使用批量命令以定时方式更新报表数据库.它似乎可能成为一个瓶颈,所以我们还希望在这一点上增加一些可扩展性 - 一个集群解决方案.但是在集群的情况下,我们无法控制报告数据库更新的顺序(或者我们应该实现一些奇怪的,我猜错误的逻辑将检查报告数据库中的对象版本).另一个问题是解决方案的可持续性:如果出现故障,我们将在非规范化程序中丢失更新,只要我们不将其保留在任何地方).所以现在我看来解决这个问题(Denormalizer可扩展性)欢迎任何想法!
首先，您肯定希望将反规范化器托管在单独的进程中。从那里，您可以让域将域中发生的事件发布到您的消息传递基础结构。帮助加速非规范化的一种简单策略是按消息/事件类型分解事物。换句话说，您可以为每种消息类型创建一个单独的队列，然后让反规范化器订阅（使用消息总线）相应的事件。这样做的优点是，您不必将消息一个接一个地堆叠起来——一切都开始并行运行。唯一可能发生争用的地方是监听多种类型的表。即便如此，您现在已经在许多端点之间分配了负载。
只要您使用某种消息传递基础设施，您在尝试非规范化时就不会丢失事件消息。相反，在一定次数的失败重试之后，该消息将被视为“有毒”消息并移至错误队列。只需监视错误队列中的问题即可。一旦消息进入错误队列，您就可以检查日志以了解其存在的原因，解决问题，然后将其移回。
另一个考虑因素是 Mark Nijhof 的例子有些陈旧。DDD/CQRS Google Group中有许多可用的 CQRS 框架以及大量建议。