Fabric 可靠服务 vs actor 以解决 GA
Fabric reliable service vs actor in order to solve GA
目前我们有一个运行了相当长一段时间的遗传算法 (GA)，我认为我们可以使用 Fabric 来分发它，因为理论上它非常适合 microservice.这是我第一次尝试 Fabric。
我们应该怎么做？我们应该有一个 stateful service that runs and aggregates other actors tasks ? It's kinda similar to this project: https://github.com/Azure-Samples/service-fabric-dotnet-data-streaming-websockets
我不太确定该怎么做，关于这个主题的文档也不多。这个 GA 非常广泛，我们的目标是分发它的计算。
我使用 Service Fabric 实现了一个基本的遗传算法应用程序作为应用程序构建练习。不确定我的方法是否是为您的场景做事的最佳方式，但我可以描述我所做的事情。
我的应用程序只包含有状态和无状态的参与者。我有一个处理器状态参与者，它提供所有管理任务并驱动算法。因为它是有状态的，所以它保留了所产生的每一代的所有遗传状态的历史。我还有一个 FitnessEvalTask 无状态演员。该任务仅负责评估实体的适应性。它的输入是基因表示，输出是适应度值。这个想法是，您将以高速率启动此 actor 的实例，并且它们将被适当地分配。负责驱动算法的处理器应用程序将创建必要的 FitnessEvalTask 参与者实例并提供他们的输入并让他们报告他们的适应度值并在之后进行必要的处理。我的客户端进程，只是一个简单的控制台应用程序，将与处理器参与者通信以启动算法并执行任何必要的管理任务。
总的来说，我认为 Service Fabric 可以容纳像您描述的长 运行 分布式遗传算法，并且将是一个合理的解决方案。
您可能会使用 SF actors 来代表您的人口中的候选解决方案，以及（如您所描述的）SF 可靠服务来执行数据聚合、管理人口和世代等。
使用有状态还是无状态的选择 actors/services 在很大程度上取决于您是否想要（或需要）自己管理状态（例如，如果您正在与自定义数据存储集成）或者您是否SF 代表您管理状态没问题。 "stateless" SF 服务仍然可以具有持久状态...您只需负责自己管理它。
使用 SF 的好处在于，它正式地将解决方案的逻辑 + 状态与执行它所需的低级资源管理分开。您在代码中定义您的应用程序，并使用您想要的任何资源单独配置一个 SF 集群，SF 负责在集群中高效可靠地分配工作。当然你可以自己做，但要正确做是有挑战性的。
听起来是个有趣的问题...祝你好运！
目前我们有一个运行了相当长一段时间的遗传算法 (GA)，我认为我们可以使用 Fabric 来分发它，因为理论上它非常适合 microservice.这是我第一次尝试 Fabric。
我们应该怎么做？我们应该有一个 stateful service that runs and aggregates other actors tasks ? It's kinda similar to this project: https://github.com/Azure-Samples/service-fabric-dotnet-data-streaming-websockets
我不太确定该怎么做，关于这个主题的文档也不多。这个 GA 非常广泛，我们的目标是分发它的计算。
我使用 Service Fabric 实现了一个基本的遗传算法应用程序作为应用程序构建练习。不确定我的方法是否是为您的场景做事的最佳方式，但我可以描述我所做的事情。
我的应用程序只包含有状态和无状态的参与者。我有一个处理器状态参与者，它提供所有管理任务并驱动算法。因为它是有状态的，所以它保留了所产生的每一代的所有遗传状态的历史。我还有一个 FitnessEvalTask 无状态演员。该任务仅负责评估实体的适应性。它的输入是基因表示，输出是适应度值。这个想法是，您将以高速率启动此 actor 的实例，并且它们将被适当地分配。负责驱动算法的处理器应用程序将创建必要的 FitnessEvalTask 参与者实例并提供他们的输入并让他们报告他们的适应度值并在之后进行必要的处理。我的客户端进程，只是一个简单的控制台应用程序，将与处理器参与者通信以启动算法并执行任何必要的管理任务。
总的来说，我认为 Service Fabric 可以容纳像您描述的长 运行 分布式遗传算法，并且将是一个合理的解决方案。
您可能会使用 SF actors 来代表您的人口中的候选解决方案，以及（如您所描述的）SF 可靠服务来执行数据聚合、管理人口和世代等。
使用有状态还是无状态的选择 actors/services 在很大程度上取决于您是否想要（或需要）自己管理状态（例如，如果您正在与自定义数据存储集成）或者您是否SF 代表您管理状态没问题。 "stateless" SF 服务仍然可以具有持久状态...您只需负责自己管理它。
使用 SF 的好处在于，它正式地将解决方案的逻辑 + 状态与执行它所需的低级资源管理分开。您在代码中定义您的应用程序，并使用您想要的任何资源单独配置一个 SF 集群，SF 负责在集群中高效可靠地分配工作。当然你可以自己做，但要正确做是有挑战性的。
听起来是个有趣的问题...祝你好运！