了解何时使用有状态服务以及何时依赖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. 每个Aggregate都是一个只存储当前状态的actor。
2. 在命令上，聚合将影响状态更改并引发事件。
3. 事件本身存储在DocDb中。
4. 激活时，AggregateActor实例从DocDb读取事件（如果可用）以重新创建其状态。 显然，每个演员激活只执行一次。 这样可以处理actor实例从一个节点迁移到另一个节点的情况。

Answer 3

要回答@ Trond的二次问题，即“如果我们没有实现可选的持久性'，那么这是什么意思？”

actor始终是有状态服务，并且可以使用actor类上的属性配置其状态，以便以三种模式之一运行：

1. 持续存在。 状态将复制到所有副本实例，并且还会写入磁盘。 即使关闭所有副本，也会保持状态。
2. 挥发性。 状态仅复制到所有副本实例，仅在内存中。 这意味着只要一个副本实例处于活动状态，就会保持状态。 但是当所有副本都关闭时，状态将丢失，并且在重新启动后无法恢复。
3. 没有坚持。 状态不会复制到其他副本实例，也不会复制到磁盘。 这提供了最少的状态保护。

可以在Microsoft文档中找到有关该主题的完整讨论