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

Question

我晚上正在评估 Azure Service Fabric 作为我们当前 WebApps/CloudServices 堆栈的替代品，并且有点不确定如何决定具有状态的服务/参与者何时应该是有状态参与者，以及何时应该是具有外部持久状态的无状态参与者(Azure SQL、Azure 存储和 DocumentDB)。我知道这是一个相当新的产品(至少对公众来说是这样)，因此可能还没有很多关于此的最佳实践，但我已经阅读了 documentation 的大部分内容。 Microsoft 提供了此信息，但没有找到明确的答案。

我当前正在处理的问题域是我们的事件存储；我们的部分应用程序基于事件源和 CQRS，我正在评估如何将此事件存储转移到 Service Fabric 平台。事件存储将包含大量时间序列数据，并且由于它是我们持久保存数据的唯一事实来源，因此它必须保持一致、可复制并存储到某种形式的持久存储中。

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

另一种选择是让这些参与者保持无状态，让他们只从 Azure SQL 等外部存储中读取数据 - 或者只使用无状态服务而不是参与者。

基本上，什么时候 Actor /服务的状态量“太多”，您应该开始考虑其他处理状态的方法？

此外，Service Fabric Actors design pattern: Some anti-patterns 中的此部分文档让我有点困惑:

Treat Azure Service Fabric Actors as a transactional system. Azure Service Fabric Actors is not a two phase commit-based system offering ACID. If we do not implement the optional persistence, and the machine the actor is running on dies, its current state will go with it. The actor will be coming up on another node very fast, but unless we have implemented the backing persistence, the state will be gone. However, between leveraging retries, duplicate filtering, and/or idempotent design, you can achieve a high level of reliability and consistency.

“如果我们不实现可选持久性”这里表示什么？我的印象是，只要修改状态的事务成功，您的数据就会持久存储到持久存储中，并复制到至少一部分副本。这一段让我想知道是否在某些情况下我的参与者/服务中的状态会丢失，以及这是否是我需要自己处理的事情。我从文档其他部分的有状态模型中得到的印象似乎抵消了这一说法。

Answer 1

您拥有的一个选择是将“某些”状态保留在参与者中(假设什么可以被认为是需要快速可用的热数据)并将其他所有内容存储在“传统”存储基础设施上，例如如 SQL Azure、DocDB、... 对于过多的本地状态很难有一个一般规则，但也许，它有助于思考热数据与冷数据。 Reliable Actors 还提供自定义 StateProvider 的能力，因此您还可以考虑使用特定策略实现自定义 StateProvider(通过实现 IActorStateProvider)，以便更有效地满足您在数据量、延迟方面的要求、可靠性等等(注意:StateProvider 接口(interface)上的文档仍然很少，但如果您想要追求的话，我们可以发布一些示例代码)。

关于反模式:该注释更多的是关于跨多个参与者实现交易。 Reliable Actors 为参与者边界内数据的可靠性提供了充分的保证。由于 Actor 模型的分布式和松散耦合特性，实现涉及多个 Actor 的事务并不是一项简单的任务。如果“分布式”事务是强烈要求，那么 Reliable Services 编程模型可能更适合。