我们自2010年以来一直在Azure上，并从我们的应用程序中的性能和可靠性中获益匪浅。 Azure提供了许多企业级服务，我认为新的“Azure Service Fabric”非常棒。
阅读文档时我无法理解的是将“旧”Cloud Service迁移到新的Service Fabric的方法。我们为什么要迁移？用于水平缩放和更高可靠性。
目前我们有一个单实例云服务，它可以提升很多子服务。这些子服务是微服务的理想选择。唯一的问题是这些子服务中的一些是“跑步者”，即他们只是在我们的用户数据库上循环并决定是否必须为特定用户运行操作（服务）。 考虑到多个实例可以运行此服务，您将如何迁移此类服务？
由于
答案 0 :(得分：0)
首先要记住的是，一旦服务启动它就会继续运行，并且他的生命周期和正常运行时间由Service Fabric控制（例如：它会在崩溃时自动重启）。要记住的第二件事是，您最终会同时运行多个服务实例（在不同的节点上），因此它们最终会在群集的不同节点上执行完全相同的操作。
你的第一反应可能是每个跑步者有一个无状态服务种类/实例＆＃34; subservice＆＃34;继续运行并利用RunAsync（https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-reliable-services-advanced-usage）。就个人而言，我不会采用这种方法，因为这可能需要在服务之间进行某种同步以防止无用的并发，因为它们完全相同。
更好的方法是让你的跑步者服务需要在＆＃34; main＆＃34;的要求下偶尔运行一次。作为协调者的服务，你可以有一个基于队列的方法，其中＆＃34;主要＆＃34;服务提交要由同时侦听同一队列的运行者处理的任务（消息），确保最多一个服务实例完成任务。
对于队列，请考虑Service Bus或Reliable Concurrent Queue（https://docs.microsoft.com/enus/dotnet/api/microsoft.servicefabric.data.collections.preview.ireliableconcurrentqueue-1）。