c# - MVC - WCF - RabbitMQ - 通过消息队列到消费者的域事件加速或替代方案？

Question

领域驱动设计将事件传递给单独的限界上下文

---

MVC 中的用户操作应生成一个事件，该事件将传递到远程(同一 LAN)事件处理程序。

我测试过的内容:

1. MVC:即发即忘服务调用(异步)->
2. (IIS 托管)WCF，用于收集数据并填充消息 ->
3. 通过 EasyNetQ/RabbitMQ ServiceBus 发送 ->
4. 事件由处理事件及其数据的订阅者(使用从 WCF 服务端点初始化的 DI 容器)使用。

我做了一些测试，看看如果通过在 MVC 端循环相当快地调用服务，它会如何工作

for (int i = 0; i < 200; i++)
{
        ...
        client.MyServiceMethod(someId, startDate); 
        ...
}

MessageQueue 部分速度很快，基于它发送到队列并由订阅者在同一秒内接收到的时间戳。循环 WCF 服务调用非常慢。循环它们需要很多秒。我尝试从 wsHttpBinding 切换到 netTcpBinding，并在 WCF 中使用 serviceThrotdling。

WCF 不是强制性的，但似乎一个单独的事件处理项目(在发布商端)会有所帮助，并且可以物理上位于 MVC 应用程序的其他位置(减少负载等)。 WCF 对于这种情况是否可行，或者我应该尝试使用 Windows 服务或其他一些自托管服务，例如控制台应用程序等，或者可能使用 MVC 中的线程来生成事件数据，或者是否有更好的方案？此类事件处理系统的最佳实践是什么？基本上，让某些东西生成事件数据似乎是有益的，因为它必须在某个地方进行处理，同时又不会减慢最终用户正在使用的 UI。

Answer 1

我认为您最好使用 NServiceBus 这样的工具，而不是尝试像这样部署自己的基础设施。 (不是免费的)或MassTransit (自由的)。 (我会考虑这是最佳实践。)

我不能代表 MassTransit，但我对 NServiceBus 的体验非常好。您只需要指定哪些消息进入哪个队列。您可以使用多种不同的排队技术，但我建议从默认的 MSMQ 实现开始。无需 WCF 配置噩梦。 ;)

您的所有消息处理程序也将自动包装在分布式事务中，以便如果数据库交互失败，整个消息将回滚，您将来可以再次尝试该消息。