背景
云应用程序和服务本质上是并行和分布式的。它们也具有互动性和动态性; 通常需要云实体之间的近实时直接交互。今天很难建立这样的应用程序。开发过程需要专家级程序员，并且随着工作负载的增长，通常需要昂贵的设计和体系结构迭代。
今天的大多数高规模的特性都是作为无状态的n层服务的组合而构建的，大多数应用程序逻辑都位于中间层。
虽然该模型允许通过向中间层，添加更多服务器来扩展，但它受到存储层的性能和可扩展性的限制，因为从前端Web服务器，进入中间层的大多数请求，需要从存储中读取一个或多个。由于中间层服务器之间缺乏协调，更新变得更加复杂，并且容易出现并发问题和冲突。它通常需要在无状态层中进行缓存，以获得可接受的性能，增加复杂性并引入缓存一致性问题。无状态n层模型的另一个问题是，它不能很好地支持中间层暴露的各个应用程序实体之间的水平通信。
Orleans作为有状态的中间层
Orleans提供了一种构建有状态中间层的直观方式，其中各种业务逻辑实体，表现为分布在服务器集群（silos）上，不同应用程序的类型定义，隔离海量的全局可寻址.net对象（grains）。
grain类型是一个简单的.NET类，它实现一个或多个应用程序定义的grain接口。单个grains是应用程序定义的grain类的实例，它们可以根据需要由服务器上的Orleans运行时自动创建，以处理对这些grains的请求。grains自然映射到大多数应用程序实体，例如用户，设备，会话，库存和订单。这使得构建面向对象的业务逻辑变得非常容易，但是在服务器集群中透明地扩展。每个grain在其应用逻辑选择的grain类型内，具有稳定的逻辑标识（密钥），例如，用户电子邮件或设备ID或库存SKU代码。Orleans保证每个单独grain的单线程执行，从而保护应用程序逻辑免受并发和竞争的危险。
Grain生命周期
grain在存储，内存状态或两者中，都可以具有持久状态。通过使用目标grain的逻辑身份，任何其他grain或前端（客户端）都可以调用任何grain，而无需创建或实例化目标grain。Orleans的编程模型使得grains，看起来就好像它们一直存在于记忆中。实际上，grain从存在的整个生命周期中经历，只是作为存储中的持久状态，在内存中实例化，从内存中移除。
在后台，Orleans运行时会在他们有工作的时候，实例化（激活）grains，并在谷物空闲时间过长时，将其从内存中移除（停用）以回收硬件资源。运行时的grain生命周期管理工作，对应用程序代码是透明的，并将其从分布式资源管理的复杂任务中解放出来。应用逻辑可以用可用的grains的整个“地址空间”编写，而无需具有硬件资源来同时将所有grains保留在存储器中，概念上类似于虚拟存储器在操作系统中的工作方式。此外，
虚拟参与者
Orleans的实施基于自20世纪70年代以来一直存在的参与者模式 。然而，与Erlang或Akka等更传统的参与者模式系统中的参与者不同，Orleans grains是虚拟参与者。最大的区别在于，grains的物理实例完全被抽象出来，并由Orleans运行时自动管理。虚拟参与者模型更适合云服务等高规模动态工作负载，是Orleans的主要创新。您可以Orleans技术报告中阅读更多详细信息。
Orleans的起源
Orleans是在Microsoft Research创建的，专为在云中使用而设计。自2011年以来，它已被多个微软产品组广泛应用于云中和内部，最着名的是游戏工作室，如343 Industries和The Coalition，作为Halo 4和5背后的云服务平台，以及战争机器4 ，以及其他一些公司。
Orleans于2015年1月开源，吸引了许多开发人员，他们构成了.NET生态系统中最具活力的开源社区之一。在开发人员社区与Microsoft Orleans团队之间的积极协作中，每天都会添加和改进功能。微软研究院继续与Orleans团队合作，推出新的主要功能，如地理分布，索引和分布式事务，这些都推动了最先进的技术发展。Orleans已经成为许多.NET开发人员构建分布式系统和云服务的首选框架。
官方文档：http://dotnet.github.io/orleans/Documentation/index.html