像 AKKA.net 这样的参与者模型带来了许多好处，例如可伸缩性、反应性、内存缓存等......当我尝试将 AKKA 与Azure 服务总线队列进行比较时，我看到了几乎相同的主要好处Azure 服务总线，内存缓存的好处除外。
在生产环境中，AKKA 需要多个具有更多内存、处理能力的 VM 来处理内存中的数百万演员。对于 Azure 服务总线队列，不需要强大的主机。即使我们使用 Actor 模型，也不需要进行监督或创建 Actor 系统来管理数百万个 Actor。Azure 服务总线的可伸缩性是自动的。
从长远来看，我认为 Azure 服务总线队列具有成本效益。随着负载的增加，不需要 IT 管理员来管理它。也不需要具有多核的强大系统。
AKKA 参与者模型是否适合具有多核系统的本地数据中心，而不适合在考虑成本效益时可以使用 Azure 服务的应用程序？
我会说 Akka.net 的邮箱组件所做的工作类似于 Azure 服务总线队列（或实际上是 MSMQ）在原则上可能相似的工作。在服务总线队列（或 MSMQ）将持久存在的情况下（或者在 MSMQ 的情况下，持久队列 - 不是内存队列）存储的消息和 Akka 开箱即用的邮箱不会。
但这就是相似之处的结束……服务总线没有演员、处理器、分发的概念——它只是一个消息传递解决方案。
如果您希望实现可能以持久性（和事务性“演员”）为目标的演员，那么我建议您不要使用 Akka.net，而是使用 MassTransit 或 nServiceBus。两者都是非常有能力的产品，虽然它们的性能不及 Akka.net（MT 和 nSB 序列化并持久化到磁盘，Akka.net 没有），但它们非常有能力和坚固，并且当一个 Actor/Node 崩溃时可以透明地恢复整个工作项将在一个事务中，这将导致消息被重新插入/重新处理为默认行为。
长期以来，我一直将 Azure 表存储视为一个很好的事件存储，但如果您希望保留命令记录，我会使用服务总线（MassTransit，nServiceBus），而对我而言，这感觉就像您有更多“事务性”的需求”本质上是“近实时”和“多处理器”。
我个人的看法，