Orleans 解决并发之痛（三）：集群

Orleans 本身的设计是一个分布式的框架，多个 Silo 构成集群，Grains 分布在多个 Silo 中。一旦一个 Silo 挂了，原来归属这个 Silo 的 Grains 会自动在其他 Silo 中激活。生产环境下还是需要以集群方式来部署。

cluster

在[ Orleans 解决并发之痛（二）：Grain 状态] (http://www.jianshu.com/p/ccd9cffa77bf)文章中提到内存存储State是不靠谱的，同样，以内存方式存储集群中 Silo 的成员关系也是不靠谱的，所以本文使用 SQL Server 来做 Silo 的成员关系存储，以内存方式存储成员关系存在主节点之说，其他节点的启动必须依赖主节点的启动状态，但以 Azure Table、SQL Server 、ZooKeeper、Consul 等存储成员关系，所有的 Silo 都是平等的，不需要等待谁。

之前在 Orleans 解决并发之痛（一）：单线程 Demo 中是以内存存储集群成员关系的，有兴趣可以返回查看。

这篇文章的 Demo 是 Orleans 解决并发之痛（二）：Grain 状态的基础上完成的，所以在原来代码的基础上做一些调整即可。我们会启动3个 Silo，构建成一个集群环境，实际上提供3个配置文件即可，配置文件稍做修改就可实现。

Silo 配置文件

OrleansConfiguration1.xml：

OrleansConfiguration2.xml 和 OrleansConfiguration3.xml 除了 Networking 、ProxyingGateway 配置有所区别，其他完全一样。

OrleansConfiguration2.xml：

OrleansConfiguration3.xml：

这次配置文件中引入了一个 SystemStore 节点：
SystemStoreType：存储的类型；如：AzureTable、SqlServer、ZooKeeper等；
DeploymentId：部署的唯一 Id 标识，具有相同的 DeploymentId 的 Silo 会加入一个集群中；
DataConnectionString：连接字符串；

3台 Silo 启动成功后，在 OrleansStorage 库的 OrleansMembershipTable 表中会记录下成员关系：

systemStore

Client配置文件

ClientConfiguration.xml：

Client 通过 DeploymentId 标识连接 Silo 集群。具体最终调用那个 Silo 完成方法的调用，由其内部调配。当某一台 Silo 挂了，Grain 会重新在另一个 Silo 上激活，达到高可用状态。

Client 的测试代码：

我们用一个死循环，创建很多 Grain，来观察 Silo 控制台的输出效果

var random = new Random();
while (true)
{
  Thread.Sleep(1000);
  var grainId = random.Next().ToString();
  var grain = GrainClient.GrainFactory.GetGrain("Test-" + grainId);
  grain.SayHelloAsync();
}

测试结果：

从控制台输出结果来开，每台 Silo 上 Grain 的分配还是比较均匀的

Test Result

当杀掉一个 Silo 后，服务依然是正常运行，具体 Grain 是否重新被分配有兴趣可以测试一下：

Test Result2

参考链接：

Actor 模型
Orleans
案例 Demo-OrleansCluster