上节中我们谈到了Service Fabric最底层的两个概念,一个是针对硬件层面而言的Node Type和Node。另一个是Application。
Node Type是Node的集合,Node是对部署机器的概念抽象。对Service Fabric而言,Node可以是物理机,虚拟机,甚至现在最主流的Container。
在Node Type上运行的是Application。它是针对系统软件层面的抽象理解。一个Application中包含了多个Micro Service。甚至Service Fabric的所有基础服务,例如FailoverManager Service,Naming Service,也都是Micro Service。
Service Fabric所有分布式特性都对应于Micro Service展开。我们可以动态调整一个Micro Service需要在多少个Node上运行多少个实例来分摊负载压力,或者进行容灾备份。每一个实例都会监听不同的端口,由负载均衡层将请求分布至不同实例上。
实际场景
Stateful Service是其中的一种Micro Service。
在开始介绍Stateful Service之前,让我们来考虑下面这种很常见的业务场景。
你正在考虑实现网站里面的购物车功能。用户登录后会放置一些商品在自己的购物车中。
用户下次登录,前台页面会调用购物车服务,并需要从这个服务重新读取已经保存的购物车数据并用以显示。
如果是你会怎么实现?
如果在用户量不是特别大的一般情况下,我们会在数据库中添加一张购物车表,和用户表进行关联。该购物车表中会有一个用户ID字段,并且记录大量的用户购物车数据。
那么这样就会带来一些后续问题。
这种问题的根源在于,首先系统本身的设计不是面向可扩展的。另外数据库是一个性能潜在的瓶颈和威胁。
Stateful Service
让我们考虑这样一种全新的架构。
从一开始,购物车系统就由36个子服务来处理所有的请求(36个是因为用户ID的首字母是 0-9 a-z,一共36种)。
用户的请求,会根据用户ID首字母hash至某个特定的子服务来处理。
子服务把购物车数据通过轻量级数据库方式保存在自己内部,并且持久化到自己所在的存储设备上。
每个子服务还有3个备份,这些备份在不停同步保存的数据,同时这些备份永远运行在不同的Node上。
同时只有一个备份作为激活状态来负责处理请求,当激活备份出现问题,另外两个备份根据调度算法激活一个。
容灾子系统再创建一个新的备份,永远保证该子服务有3个健康的备份。
Stateful Service就是这样的一种解决方案。
回到上面的场景,购物车系统就是一个Stateful Service。
36个子系统就是这个Stateful Service的36个实例,我们叫Partition。
每个子系统下的备份就是Replica,一个partition有3个Replica。
当前激活的备份就是Active Replica,两个未激活的待命备份就是Secondary Replica。
同一个Partiion的每个Replica都一定运行在不同的Node上面。
Stateful Service代码通过IReliableCollection<T>,IReliableDictionary<T1, T2>等接口来进行数据保存和内部同步。
此外,Stateful Service还可以实现以下特性。
希望以上的介绍可以帮助大家更好的理解Stateful Service。
我们会在后面的章节中介绍Stateful Service的代码示例。
from:http://www.cnblogs.com/mschiefevangelist/p/6441496.html