.net – CQRS EventSourcing可扩展性

发布时间：2020-12-16 03:44:20 所属栏目：asp.Net 来源：网络整理

导读：我正在尝试在我的新项目中使用CQRS和EventSorcing.我跟随Greg Young几年前提出的方式(Mark Nijhof实施 – http://cre8ivethought.com/blog/2009/11/12/cqrs–la-greg-young/).我有一些与此解决方案的可扩展性有关的问题. Mark Nijhof在this文章中提到了一些

我正在尝试在我的新项目中使用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可扩展性)欢迎任何想法！

解决方法

首先,您肯定希望将denormalizer托管在一个单独的进程中.从那里,您可以让域发布到您的消息传递基础结构中域中发生的事件.帮助加速非规范化的一个简单策略是通过消息/事件类型将事物分开.换句话说,您可以为每种消息类型创建一个单独的队列,然后让denormalizer订阅(使用消息总线)到相应的事件.这样做的好处是你没有消息堆叠在一起 – 一切都开始并行运行.您可能有争用的唯一地方是在监听多种类型的表上.即便如此,您现在已经在许多端点之间分配了负载.

只要您使用某种消息传递基础结构,就不会在尝试反规范化时丢失事件消息.相反,在一定次数的故障重试之后,该消息将被视为“毒药”并移至错误队列.只需监视错误队列中的问题.一旦消息在错误队列中,您可以检查日志以查看它的原因,解决问题,然后将其移回.

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

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!