我有一个基于 MassTransit 和 RabbitMQ 的现有分布式计算框架。本质上，有一个经理根据请求响应工作。每个工人都会根据物理机规格拿走一定数量的物品。然后，工作人员在完成后发送完成消息。它工作得相当好并且似乎具有高度可扩展性，因为唯一的链接是服务总线。
我最近评估了 Akka.Net，看看它是否是一个更简单的系统来实现相同的模式。看完之后，我有点困惑它到底是做什么用的。似乎如果我想做类似的事情，经理必须提前了解每个工人并直接发送工作。
我相信我遗漏了一些东西，因为该模型似乎无法很好地扩展。
像 MassTransit 这样的服务总线被构建为可靠的消息服务。确保消息传递是那里的主要关注点。
Actor 框架也使用消息，但这是唯一的相似之处。消息传递只是实现目标的一种手段，它不像服务总线那样可靠。他们更倾向于构建高性能、易于分布式的系统拓扑，以参与者为主要工作单元。从概念上讲，actor 接近 Active Record 模式（但是这是一个很好的简化）。它们也非常轻巧。你可以让数以百万计的它们生活在执行机器的内存中。
在性能方面，Akka.NET 能够在单个 VM 上每秒发送超过 3000 万条消息（在 8 个内核上测试）——比任何服务总线都要多得多，但特性也有很大不同。
在 JVM 上我们现在认为 akka 集群可能会上升到2400 台机器。不幸的是，我们无法测试 .NET 实现的限制是什么。
你必须决定你真正需要什么：一个消息传递库、一个actor框架或两者的组合。
我同意@Horsiath 的回答。另外，我想说的是，在大多数情况下，您可以为像akka 这样的参与者模型的消息传递系统替换服务总线，但它们不在同一个类中。
消息传递只是 Akka 提供的一件事，虽然它是一个很棒的功能，但我不会说它是主要功能。在分析它作为替代方案时，您必须首先查看模型本身的好处，然后查看消息传递功能是否足以满足您的用例。例如，您仍然可以使用专用的外部服务总线在不同的集群之间分发消息，并保持 akka.net 在集群内交换消息。
但关键是，如果您决定使用 Akka.net，您将不会只将它用于消息传递。