转载

.NET的Actor模型：Orleans

Orleans 是微软推出的类似 Scala Akka 的 Actor 模型， Orleans 是一个建立在 .NET 之上的，设计的目标是为了方便程序员开发需要大规模扩展的云服务 , 可用于实现 DDD+EventSourcing/CQRS 系统。

传统的三层体系结构包括无状态的前端 , 无状态的中间层和存储层在可伸缩性方面是有限制的，由于存储层在延迟和吞吐量方面的限制，这对于每个用户请求都有影响。通常办法是在中间层和存储层之间添加缓存层来提高性能。然而，缓存会失去了大部分的并发性和底层存储层的语义保证。为了防止缓存和存储池的不一致更新，应用程序或缓存管理器需要实现一个并发控制协议。

无论是否使用缓存，无状态中间层并不提供本地数据，因为它使用的是数据装载范式 : 对于每个请求，数据是来自存储层或缓存加装到中间层，如果是一个社会关系图，一个请求将会激活关联很多子实体对象，这就对缓存一致性带来更大的挑战。

Actor 模型提供了一个解决这些挑战的有吸引力的依靠函数装载的范式。 Actor 允许建立一个有状态的中间层，缓存的性能优势与封装的数据局部性都通过特定于应用程序的业务实体封装协调了（ DDD 的聚合根用行为守卫状态，聚合根保存在缓存中，聚合根实体的状态字段也在缓存中，对状态字段的操作只能通过实体行为，保证状态一致性）。此外 ,Actor 容易实现中间层中水平的、"社会"、实体之间的关系。

分布式系统编程的另一个观点是面向对象编程 (OOP) 。虽然 OOP 是一个建立复杂系统模型直观的方法，但是他被受欢迎的面向服务的体系结构 (SOA) 边缘化了。当然人们仍然可以受益于 OOP 实现服务组件时。然而，在系统层面上 , 开发人员必须考虑松耦合的分区服务，通常会导致和应用程序的概念业务对象不匹配，这导致了目前主流方向由开发人员构建分布式系统非常困难。 Actor 模型将 OOP 带回了系统级开发，开发人员非常像熟悉交互的对象的模型。

例如 Erlang 和 Akka 的 Actor 平台在简化分布式系统编程方面是向前迈出了一步。然而 , 他们仍然负担与许多分布式系统的复杂性，因为开发人员面临相对低水平的抽象和系统服务。关键的挑战是开发管理 Actor 生命周期的代码，处理分布式竞争、处理故障和恢复 Actor 以及分布式资源管理等等都很复杂，因此，如果建立一个应用程序必须正确的解决这些问题，开发人员则必须是一个分布式系统专家（难度太大）。

为了避免这些复杂性，微软研究院建造了 Orleans 的编程模型，运行时它提高了 Actor 的抽象级别。 Orleans 的目标不是分布式系统专家级别的开发人员，虽然我们的专家客户发现它也有吸引力。和现有的基于 actor 平台有本质差异，它是把 Actor 作为虚拟实体 , 而不是实际物理的。

首先，一个 Orleans 的 Actor 总是存在的，但是它不能被显式地创建或销毁。它的存在超越任何内存中任何实例的生命周期，从而超越了任何特定服务器的生命周期。

第二， Orleans Actor 是自动实例化 : 如果内存没有 Actor 实例，它会自动创建，发送到 Actor 的一个消息是当前服务器上创建一个新的实例。一个未使用的 Actor 实例作为运行时资源管理的一部分自动回收。一个 actor 实例从来不会失败 : 如果服务器 S 崩溃 , 发送给这个 S 中 Actor 的下一个消息将被自动实例化到另外一个服务器 A ，消除应用程序需要监督和人为编码显式地重建失败的 Actor 。

第三， Actor 的位置实例对应用程序代码是透明的 , 这极大地简化了编程。

第四， Orleans 可以自动创建多个实例相同的无状态的 Actor ， Actor 可以无缝地热扩展。

Orleans 给开发人员一个虚拟" Actor 空间" , 类似于虚拟内存，使他们能够调用系统中的任何 Actor ，不管它是否存在于内存。虚拟化间接依赖从虚拟 Actor 到实际 Actor 的映射。这种级别的间接寻址为运行时解决许多分布式系统问题带来机会，否则开发人员必须直接自己解决这些复杂问题，如 Actor 定位和负载平衡、失活未使用的 Actor, 复苏因服务器失败的 Actor, 这是出了名的困难。因此 , 虚拟 Actor 方法大大简化了编程模型。同时允许运行时加载和透明地从失败中恢复。