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