Orleans入门例子

　Orleans是微软开源的分布式actor模型框架.actor模型的原理网络上有很多文章.有许多理论性的文章,深刻地我都不知道怎么应用.在这里我就不赘述了.既然是博客,就说说自己的理解。

对于编程来说，不管是前台还是后台，在现在的计算机环境下，多线程编程是不可避免的。多线程带来的很多好处，也带来的很多编程上的“坏处”。好处就是，什么并发、高效，高资源利用率等等高大上的词语。这些就不详细说了。就说说坏处.

多线程带来的最大的变化就是：我先前保存的变量A，在我想要再次利用它的时候，A是否被其他线程给更改了？数据库中叫脏读，我们拿过来用，“避免脏读”又有个同义词叫做“操作的原子性”。为了解决脏读的问题，有一下几种办法： 

　　办法一变量A在初始赋值的时候，就规定它不可以被更改，就是不可变，英文叫做immutable，很多函数式语言如F#，scala等都有不可变量。既然量是不可变的。就不会有什么脏读问题了。这真是个好办法，但是在C#和JAVA这样的语言里，这不是个好办法。

　　办法二就是大家经常使用的，多线程，架锁。精巧的设计类，小心的使用这些来，管理各种资源的竞争。为了避免脏读，在C#以及JAVA里，架锁是一个可行的办法。但是这样会使得效率变低（锁架地多了，这个会更明显），更为关键是带来逻辑的复杂性。架锁的程序，可以说是一个“正确但是脆弱”的程序。离开了初创人员，后来的人想读懂读透？呵呵，人生苦短。

　　办法三，也是Orleans采用的办法，设计一个类，保证这个类从“创建”过程到“销毁”过程，以及“中途调用它的方法”的执行过程，这三个“过程”不管何时何地调用，都会在同一个线程中运行。这样的化，我就可以放心大胆的去修改，调用这个类的方法，而不用担心这个指向这个类的变量出现“脏读”的情况。这个某种程度上算是办法一和二的折中。为了说明这个办法，就不得不说Actor模型。 

　　人与人的沟通只是通过消息,不管是听闻嗅触等等感觉,都是往外界往人的身体发送的消息.人处理后做出反应.这个处理与反应是异步的.接受消息和处理消息都是并行的、同时的进行。actor模型就是模拟这种通信方式.用Actor作为名称,也算是指明了这个模型想要模拟什么。

　　既然是模拟，那就是简单化。Orleans模型里，每一个actor有专门的类代表它，叫做Grain，这个grain类就是模拟通信场景中的”人”,但是Orleans为了解决多线程带来的“资源竞争”等问题，采用了办法三，再Orleans框架内，它保证每个grain类符合以下行为规范：

　　A． 发往同一个grain类实例的任何消息都会在固定线程内执行。

　　B． grain类按照接受消息的先后，依次处理消息。在任意时间点，一个grain实例只处理一个消息。

　　C． grain实例内的字段属性，只能由实例本身访问。外界不能访问。 

　　在大部分情况下，这些规范都是成立的。这些规范被称为“单线程机制”。但是也要有“变通”，这些“变通”涉及到很多其他方面，在以后的文章中会解释是如何变通的，为什么要变通，以及什么场景下才需要变通。不过现在你可以认为，这些规则就是“法律”。在Orleans的框架内，这些grain们都是一些“头脑简单并且自闭的人”。你作为设计者，如果恰到好处的布置这些“人”，它们会给你惊喜。比如对于消息的处理，可以做到全程无锁等。。。高大上的特性。

　　同时Orleans是使用Actor模型的，同时微软更近了一步，它是使用的虚拟的Actor模型。具体怎么个虚拟法，这个以后的文章中解释。

　　以上说了那么多，就说明Orleans是使用actor模型的。还没有说分布。Orleans是分布式的。那是因为所有Actor之间的互动是跨线程的，甚至是跨计算机的。同时Orleans框架保证开启多个服务端程序实例，通过简单的配置，它们的行为就会如同单一的服务端实例一样。客户端感觉不到区别，简单的说就是服务端能“合体”。两个小奥特曼，每个小奥特曼由更小的细胞组成，同时他们又合体变成了一个大的奥特曼，就问你怕不怕，你如果不怕，Orleans甚至实现了“合体的合体”---这种横向扩展性为高可用，资源的充分利用以及大吞吐量带来可很大的想象空间，同时也是灵活部署的基础。另外利用Orleans的Actor模型，也可以很容的实现event sourcing。它甚至已经内置了event sourcing中间件。

　　Orleans同时也有Net.Core版本,利用它可以实现跨平台运行,它名字叫做Orleans vNext.我是按照framwork版本写的。两个版本的使用方法几乎相同。