1.背景

构建能够横向扩展的高可用应用不是一件易事。服务的可用性和延迟直接影响后续用户的使用体验。为了能够及时响应大量用户同时发起的会话，服务的吞吐量也有很高的要求。

无状态前端和业务层及数据储存层的传统三层架构，由于数据储存层对每一次请求的响应的延迟和并发量的限制影响了横向扩展的能力。为了提升性能，虽然在储存层及业务层之间添加数据缓存能够进行缓解，却丢失了底层存储层并发性和可靠性保证。应用程序或缓存管理不得不实现防并发锁，避免缓存被并发更新导致一致性的丢失。由于数据传输范例（data shipping paradigm）的使用，无论有无缓存无状态的中间层都无法实现数据局部性：数据需要从储存层或缓存传递给中间层服务器来完成每个请求。

The advent of social graphs where

a single request may touch many entities connected dynamically

with multi-hop relationships makes it even more challenging

to satisfy required application-level semantics and consistency

on a cache with fast response for interactive access.

参与者模式通过函数传输范例（data shipping pradigm）来应对这些挑战。通过构建一个有状态的中间层来达到具备数据局部性的缓存的性能，再通过应用语义的操作实现实体在语义上的概括统一。另外，参与者模式还能使中间层的网状关系的横向调用变得简单。

分布式系统可编程性还需考虑面向对象编程（OOP）范式的问题。虽然通过直觉对复杂系统进行建模的面向对象编程模式已被面向服务架构（SOA）边缘化，但是还是能够在组件实现过程中获得面向对象编程的益处。然而，从系统层面考虑，开发者按松耦合划分的服务经常与应用的概念模型不符。对于大多数开发者来说，这种不符为分布式系统的构建带来难度。参与者模式通过与模型交互非常相似的参与者将面向对象重新带回系统级别。

像Erlang及Akka这样的参与者平台是简化分布式系统编程的一步。然而这些平台因为分布式系统自身的复杂性及平台提供的相对低度抽象仍然会加重开发者的负担。挑战的核心是对应用程序代码中的参与者进行生命周期的管理、对内在的分布式资源争夺进行处理，对失败的参与者进行恢复，参与者的待机以及分布式资源的管理。开发者只有成为分布式的专家才能，面对应用程序中的这种问题，进而构建一个恰当的解决方案。

为了避免这些复杂情况，我们构建了Orleans编程模型及运行时来提高参与者的抽象程度。Orleans获得了分布式系统专业用户的青睐，与此同时也适用于普通的开发人员。Orleans是基于参与者的平台，但是与现有平台不同的是：参与者是虚拟的实体，而不是物理实体。第一，Orleans的参与者总是虚拟的存在，其不能明确的创建或销毁。其超越了任何内存中的实例及服务的生命周期。第二，Orleans的参与者会自动完成实例化：如果内存中没有参与者的实例，参与者会收到使其在服务器中进行实例化的消息。不可用的参与者实例的回收工作是运行时资源管理的一部分。参与者永远不会失效，如果S服务器崩溃，Orleans会在另一台服务器重新实例化A参与者来接收发送给S服务A参与者的消息， eliminating the need for applications to supervise and explicitly re-create failed actors.三，参与者的实例位置非常易于编程，其对于应用程序代码是透明的。四，Orleans能够自动的构建相同状态的复数实例进行无缝横向扩展的热切换。

总的来说，Orleans了一片类似虚拟内存的虚拟的“参与者空间”，无论系统中的actor此刻是否在内存中，开发者都能够随时对其进行调用。其虚拟化依赖于虚拟的actor与当下正在运行的物理实例的间接映射。这种级别的间接映射的运行时，提供了需要开发者亲自处理的强分布式系统的问题的机会，例如参与者空间、负载均衡、释放未使用的参与者、参与者的故障恢复。这样，虚拟的参与者将显著的精简编程模型，通过运行时来完成负载均衡和故障恢复。

Orleans使用很小的运行时通过分发目录提供间接的支持。通过参与者身份与其真实物理位置的映射缓存，Orleans也会最小化运行时的性能损失。这种策略是十分奏效的，在我们的产品服务中，缓存的命中率可以高达90%。

Orleans构建的若干产品服务一些主流游戏的后端服务，已在Windows Azure云中进行托管。这些服务使我们可以基于其模型和接口验证Orleans构建的产品应用的可靠性及弹性。这至少能从侧面验证Orleans编程模型可以显著的提升编程的生产力。

While the Orleans programming model is appropriate for many applications, certain patterns do not fit Orleans well. One such pattern is an application that intermixes frequent bulk operations on many entities with operations on individual entities. Isolation of actors makes such bulk operations more expensive than operations on shared memory data structures. The virtual actor model can degrade if the number of actors in the system is extremely large (billions) and there is no temporal locality. Orleans does not yet support cross-actor transactions, so applications that require this feature outside of the database system are not suitable.

简而言之，这篇论文的主要贡献是，（a）这种新颖的虚拟参与者抽象方式提供了精简的编程模型。（b）对比传统的参与者框架相比，一个性能良好及可扩展的分布式参与者模型接口会一定程度的提高性能及可扩展性。并且（c）此结论来源于生产经验的评估和描述。

这篇论文的提纲如下：第二节介绍了Orleans编程模型；第三节解释了运行时如何通过虚拟参与者模型提升弹性和可扩展性；第四节讨论了Orleanse在实践中如何应用；第五节阐述了产品的评估与测试基准；第六节是Orleans与其他参与者框架的比较以及早期Orleans的源性报告。第七节总结。