目前我们有一个运行了很长时间的遗传算法 (GA)，我认为我们可以使用 Fabric 分发它，因为理论上它非常适合作为 microservice。这是我第一次尝试 Fabric。
我们应该怎么做？我们是否应该有一个 stateful service 来运行和聚合其他 actors 任务？有点像这个项目：https://github.com/Azure-Samples/service-fabric-dotnet-data-streaming-websockets
我不太确定该怎么做，而且关于这个主题的文档也不多。这个 GA 非常广泛，我们的目标是分发它的计算。
【问题讨论】：
标签： c# azure actor genetic-algorithm azure-service-fabric
我使用 Service Fabric 实现了一个基本的遗传算法应用程序作为应用程序构建练习。不确定我的方法是否是为您的场景做事的最佳方式，但我可以描述我做了什么。
我的应用只包含有状态和无状态的参与者。我有一个处理器有状态参与者，它提供所有管理任务并驱动算法。因为它是有状态的，所以它保存了每一代产生的所有遗传状态的历史。我还有一个 FitnessEvalTask 无状态演员。该任务仅负责评估实体的适合度。它的输入是基因表示，它的输出是适应度值。这个想法是你会以高速率旋转这个actor的实例，并且它们会被适当地分布。负责驱动算法的处理器应用程序将创建 FitnessEvalTask 参与者的必要实例并提供他们的输入，并让他们报告他们的适应度值并在之后进行必要的处理。我的客户端进程只是一个简单的控制台应用程序，它将与处理器参与者通信以启动算法并执行任何必要的管理任务。
【讨论】：
Task<double> EvaluateFitnessAsync(string genes); 只需遵循具有 GetCountAsync 方法的 Actor 项目的默认项目模板中存在的相同模式。对所有参与者执行 EvaluateFitnessAsync 方法的处理器算法只是等待所有这些任务完成（Task.WhenAll 方法），然后再继续。
总的来说，我认为 Service Fabric 可以适应您描述的长时间运行的分布式遗传算法，并且是一个合理的解决方案。
您可能会使用 SF 参与者来代表您的人口中的候选解决方案，并且（如您所描述的）一个 SF 可靠服务来执行数据聚合、管理人口和世代等。
是使用有状态还是无状态参与者/服务的选择很大程度上取决于您是否想要（或需要）自己管理状态（例如，如果您正在与自定义数据存储集成），或者您是否可以SF 代表您管理状态。 “无状态”SF 服务仍然可以具有持久状态……您只需负责自己管理它。
使用 SF 的好处在于，它正式将解决方案的逻辑 + 状态与执行它所需的低级资源管理分开。您在代码中定义您的应用程序，并使用您希望的任何资源单独配置一个 SF 集群，SF 负责在集群中高效可靠地分配工作。当然你可以自己做，但要正确做是有挑战性的。
听起来是个有趣的问题……祝你好运！
【讨论】：