在.NET 中实现 Actor 模型的不同方式

上周，《实现领域驱动设计》（Implementing Domain-Driven Design）一书的作者 Vaughn Vernon ，发布了 Dotsero ，这是一个使用 C#编写的、基于.NET 的 Actor 模型工具包，它的实现参考了 Akka API。Akka 工具包是对 Actor 模型的一种实现，目前为止已经有对应 Java 和 Scala 版本的 API。

今年早些时候，微软Research 部门也发布了一个基于Actor 模型的框架， Orleans 框架的预览版。这个框架采用了云端编程模型，编写这个框架的目的在于尽可能减少创建互动式的服务时所面对的各种挑战，这些服务往往对伸缩性和可靠性有较高要求。

Orleans 团队认为，虽然 Erlang 和 Akka 这些 Actor 平台已经在简化分布式系统编程方面前进了一步，但由于它们提供了相对较低层次的抽象与系统服务，因此自身的复杂性依然很高。开发者们必须要成为分布式系统方面的专家，才有可能使用这些工具创建正确的解决方案。为了避免这些复杂性，并吸引主流开发者，Orleans 团队提升了 Actor 的抽象层次。虽然它仍然基于 Actor 模型，但与任何现有的基于 Actor 模型的平台所不同的是：它将 Actor 视为抽象的，而不是物理的实体。

最近，Vaughn 与 Orleans 项目的带头人，来自微软 Research 部门的 Sergey Bykov 在 twitter 上进行了一番讨论。Vaughn认为，Orleans 本质上并非是一种基于Actor 模型的实现，其中部分原因在于它缺少了用以支持有限状态机（FSM）的 Become 和 Unbecome 方法，而 Vaughn 认为这是 Actor 原始的定义中所必需的一部分。他同时也认为，由于在 Orleans 中 Actor 是始终存在的，那么当客户端对某个本应不存在的 Actor 发起请求时，它难以意识到这一点，从而容易引发问题。

Sergey 在回应中表示，_Become_ 只是读取定义的其中一种方式，并非Actor 模型所必需的一部分。而从他的经验来看，由于Orleans 中的Actor 始终存在，因而减少了竞态条件的产生，并且简化了恢复操作，从这方面来看由此可能产生问题的可能性比Vaughn 所说要小很多。如果某个Actor 不应该存在，那么可以通过由应用程序逻辑返回一个错误状态的方式进行处理，虽然他也承认这种方式并不够理想，但比起在创建Actor 时遇到竞态条件的情况还是要更好一些。

最近， Azure 方面的一位微软MVP ， Richard Astbury 创建了一个简单的物联网网关应用程序，以此表明他对Orleans 的观点，即Orleans 能够帮助开发者在云端创建大规模、低延迟并且适应性良好的.NET 应用程序。Richard 表示，虽然这只是个简单的示例，但它已经包含了创建更复杂的场景时所需的各种基础构建块了。

今年三月时，有一份名为《 Orleans：针对可编程性与伸缩性的分布式虚拟 Actor 》的论文专门讲解了 Orleans 背后的设计原则。

Vaughn 去年在一篇关于响应式领域驱动设计（DDD）的文章中谈论了关于 Actor 模型的话题，并且在之前的一次演讲中谈论了 Actor Model 的产生以及 DDD 的相关话题。

查看英文原文：.NET Actor Model Implementations Differ in Approach