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