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 中的 serviceThrottling。

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

Answer 1

与其尝试像这样推出自己的基础架构，我认为您最好使用像 NServiceBus 这样的工具(不是免费的)或 MassTransit (自由的)。 (我会考虑这个最佳实践。)

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

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