这对奥尔良或旧金山有意义吗？如果是这样，请指导

Question

我们正在努力将我们的软件带到 Azure 云，并将 Orleans 和 Service Fabric (SF) 视为潜在的框架。我们需要：

1. 用每个引擎实例的大量数据（例如，100MB 到 2GB）填充我们的分析引擎。
2. 保持该状态，如果引擎实例空闲 20 分钟或更长时间，我们希望将其卸载（即，不为引擎实例资源付费）。
3. 每个引擎实例将支持一个到多个具有特定数据集的最终用户。
4. 每个引擎实例都可以高度交互地生成大量近乎实时的绘图数据。我们正在维护状态，因为我们不想为每次引擎交互填充引擎实例而付出代价。
5. 引擎实例操作可能需要几秒钟、几分钟甚至几十分钟。我们需要一些反馈。
6. 用户可以每隔几秒访问一次引擎实例（例如，根据反馈引导引擎实现结果）并且需要实时绘图数据。
7. 每个用户都希望与特定的引擎实例对话。
8. 当用户表示有兴趣运行模拟（即建立引擎实例）时，理想情况下，我们希望他选择小型/中型/大型计算资源来运行他的引擎实例（即，基于他试图解决的问题解决他可能需要更多或更少的计算/内存能力）。

我们正在考虑奥尔良和旧金山，但我们很难根据上述要求指定架构。我们考虑过：

1. 尝试将 SF 分区或 Orleans silo 视为上述“引擎实例”。
2. 通过复制利用 Orleans 和 SF 的容错概念。
3. 利用本地（即，分区或孤岛）存储来存储结果和维护状态（即，长时间或直到空闲 20 分钟）。

我们不知道如何：

1. 将孤岛或分区限制为单个引擎实例，以便我们可以控制引擎实例的资源。
2. 将用户的引擎实例数据与其他用户的引擎实例数据分开。
3. 将来自用户的请求（例如，通过 Web API）定向到特定的引擎实例。

这对奥尔良有意义吗，对旧金山更有意义吗？有关如何实现上述内容的任何指示都会有所帮助。

Answer 1

当您说 SF 时，我认为您是指 SF Actors 对吧？

您可以按照您想要的方式使用它们，但在这两种情况下看起来都不是您问题的正确解决方案，因为：

1. Actor 是单线程的，如果您计划与多个客户端共享同一个实例，每个客户端都必须等待前一个客户端完成，然后才能开始处理任何内容。如果您需要监控正在运行的 Actor 的状态，则必须让 Actor 将更新发布给外部订阅者。
2. Actor 状态是隔离的，所以你不能访问其他 Actor 的状态，方法是提供一个返回它的方法，但是如果 Actor 正在运行一个命令，你必须等待完成，除非你创建一个单独的状态服务来保存处理过的数据。
3. 您无法限制参与者所需的资源，在服务结构中，您可以指定服务所需的资源，但您不能为参与者执行此操作，并且您不能限制他们使用的资源，当他们达到限制，Service Fabric 将尝试为您平衡资源，但没有什么能阻止进程消耗比请求更多的内存。
4. 两个参与者服务都使用询问方法进行通信，因此它们将“阻止”调用者等待应答，这是异步的，但您仍然必须让调用者保持“等待”状态。 （阻塞和等待是因为没有像 Akka 那样使用 Tell 方法传递消息并忘记的“即发即弃”的概念。）

根据您的一些要求，我认为容器会是更好的方法。因为：

1. 您可以限制每个容器的资源消耗
2. 数据被隔离在容器内，其他人看不到

但在容器上，您必须自己管理复制和分区，所以在这种情况下，我建议两全其美：

• 创建 SF 服务来托管用户之间的共享数据集
• SF Service+Actor 仅存储用户模拟的结果。
• 运行模拟并向参与者发送更新的容器

这只是一个示例，这完全取决于您的要求、架构以及数据如何相互隔离。