了解何时使用有状态服务以及何时依赖Azure Service Fabric中的外部持久性

Question

我正在用我的晚上评估Azure Service Fabric作为我们当前的WebApps/CloudServices堆栈的替代品,并且对于如何决定何时服务/演员与州应该是有状态的演员以及何时他们应该是无国籍演员感到有点不确定外部持久化状态(Azure SQL,Azure存储和DocumentDB).我知道这是一个相当新的产品(至少对普通大众而言),所以可能还没有很多关于这方面的最佳实践,但我已经阅读了微软提供的大部分文档而没有找到明确的回答这个问题.

我正在接近的当前问题领域是我们的活动商店; 我们的部分应用程序基于事件源和CQRS,我正在评估如何将此事件存储移动到Service Fabric平台.事件存储将包含很多时间序列 - 数据,因为它是我们持久保存数据的唯一真实来源,它必须是一致的,复制的并存储到某种形式的持久存储中.

我考虑过这样做的一种方法是使用有状态的"EventStream"actor; 使用事件源的聚合的每个实例将其事件存储在隔离的流中.这意味着有状态的actor可以跟踪自己的流的所有事件,并且我已经满足了我对数据存储方式的要求(事务性,复制性和持久性).但是,有些流可能会变得非常大(数十万甚至数百万的事件),而这正是我开始不确定的地方.我想,拥有一个具有大量状态的actor会对这些大型数据模型需要从磁盘序列化或反序列化时对系统性能产生影响.

另一种选择是让这些演员无国籍,让他们只是从Azure SQL等外部存储中读取他们的数据 - 或者只使用无状态服务而不是演员.

基本上,当演员/服务的状态量"太多"时,你应该开始考虑其他处理状态的方法吗？

此外,Service Fabric Actors设计模式中的这一部分:一些反模式文档让我有点困惑:

将Azure Service Fabric Actors视为事务系统.Azure Service Fabric Actors不是基于提交ACID的两阶段提交系统.如果我们不实现可选的持久性,并且actor在die上运行,那么它的当前状态将随之而来.演员将非常快地进入另一个节点,但除非我们实现了支持持久性,否则状态将会消失.但是,在利用重试,重复过滤和/或幂等设计之间,您可以实现高水平的可靠性和一致性.

"如果我们不实施可选的持久性",这里指出了什么？我的印象是,只要您的事务修改状态成功,您的数据就会持久存储到持久存储并复制到至少一部分副本.这一段让我想知道是否存在我的演员/服务中的状态会丢失的情况,如果这是我需要处理的事情.我从文档其他部分的状态模型得到的印象似乎抵消了这种说法.

Answer 1

您拥有的一个选项是在actor中保留"部分"状态(假设可以认为是需要快速获取的热数据)并将其他所有内容存储在"传统"存储基础架构(如SQL Azure)中,DocDB,....很难有一个关于太多本地状态的一般规则,但也许,它有助于考虑热数据与冷数据.Reliable Actors还提供自定义StateProvider的功能,因此您还可以考虑使用特定策略实现自定义StateProvider(通过实现IActorStateProvider),这些策略需要更高效地满足您在数据量,延迟方面的要求,可靠性等等(注意:StateProvider接口上的文档仍然很少,但如果你想要的话,我们可以发布一些示例代码).

关于反模式:说明更多的是关于跨多个参与者实现事务.可靠的演员为演员界限内的数据可靠性提供全面保证.由于Actor模型的分布式和松散耦合性,实现涉及多个actor的事务并不是一项简单的任务.如果"分布式"事务是一个强烈要求,可靠服务编程模型可能更适合.

Answer 2

我知道已经解决了这个问题，但是最近发现自己陷入了CQRS / ES系统的困境，这就是我的解决方法：

1. 每个集合体都是一个参与者，其中仅存储了当前状态。
2. 根据命令，聚合将影响状态更改并引发事件。
3. 事件本身存储在DocDb中。
4. 激活后，AggregateActor实例将从DocDb中读取事件（如果可用）以重新创建其状态。显然，每个演员激活仅执行一次。这照顾了参与者实例从一个节点迁移到另一个节点的情况。