我有一个基于MassTransit和RabbitMQ构建的现有分布式计算框架。基本上有一位经理根据请求回应工作。每个工人将根据物理机器规格获取一定数量的物品。工人完成后发送完成消息。它工作得很好，似乎是高度可扩展的，因为唯一的连接就是服务总线。Akka.Net工作队列
我最近评估Akka.Net为了看看如果这将是一个更简单的系统来实现相同的模式。看完之后，我对它的用途有些困惑。看起来，如果我想做类似的事情，经理就必须提前知道每个员工，并直接发送工作。
我相信我错过了一些东西，因为那个模型看起来不够好。
像MassTransit这样的服务总线构建为可靠的消息服务。确保消息传递是那里的主要关注点。
Actor框架也使用消息，但这是唯一的相似性。消息传递只是实现目标的一种手段，并不像服务总线那样可靠。他们更侧重于构建高性能，易于分布式的系统拓扑结构，以演员作为主要工作单元为中心。从概念上讲演员接近活动记录模式（不过这是一个很好的简化）。它们也非常轻巧。你可以让数百万人生活在执行机器的记忆中。
当谈到性能时，Akka.NET能够在单个虚拟机（在8个内核上测试）上发送超过30万条消息/秒 - 比任何服务总线都多，但特性也有显着差异。
在JVM上，我们现在akka集群可能会上升到2400 machines。不幸的是，我们无法测试哪些.NET实现限制。
你必须决定你真正需要什么：消息库，演员框架或两者的组合。
我同意@Horusiath的答案。另外，我想说在大多数情况下，你可以用akka等演员模型的消息传递系统替换一个服务总线，但他们不在同一个类中。
信息只是Akka提供的一件事，虽然它是一个很棒的功能，但我不会说它是主要的。在分析它作为替代方案时，您必须首先查看模型本身的优点，然后查看消息传递功能是否足够满足您的使用情况。您仍然可以使用专用的外部服务总线在不同群集之间分发消息，并保持akka.net在群集内交换消息。
但问题是，如果您决定使用Akka.net，您将不会仅将它用于消息传递。