迁移到 Azure Service Fabric - 架构注意事项
Migration to Azure Service Fabric - Architectural considerations
我们从 2010 年开始使用 Azure，并从我们应用程序的性能和可靠性中受益匪浅。 Azure 提供了很多企业级服务，我认为新的 "Azure Service Fabric" 很棒。
通过阅读文档我无法理解的是将 "old" 云服务迁移到新 Service Fabric 的方法。我们为什么要移民？用于水平扩展和更高的可靠性。
目前我们有一个单实例云服务，它启动了很多子服务。这些子服务非常适合微服务。唯一的问题是这些子服务中的一些是 "runners"，即它们只是在我们的用户数据库上循环并决定操作（服务）是否必须针对特定用户 运行。
考虑到不止一个实例可能 运行 此服务，您将如何迁移这样的服务？
谢谢
首先要记住的是，一旦服务启动，它就会保持 运行ning，并且他的生命周期和正常运行时间由 Service Fabric 控制（例如：如果它崩溃，它会自动重启）。要记住的第二件事是，您最终会同时（在不同的节点上）获得服务 运行ning 的多个实例，因此它们最终会在不同的节点上做完全相同的事情你的集群。
您的第一个反应可能是为每个 运行ner "subservice" 提供一个无状态服务 kind/instance 以保持 运行ning 并利用 RunAsync（https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-reliable-services-advanced-usage ).就个人而言，我不会采用这种方法，因为这可能需要服务之间进行某种同步以防止无用的并发，因为它们独立地做完全相同的事情。
一个更好的方法是让您的 运行ner 服务需要 运行 仅当 "main" 服务作为协调器请求时，您可以一种基于队列的方法，其中 "main" 服务提交任务（消息）由 运行ners 处理，他们同时监听同一个队列，确保最多一个服务实例可以完成任务。
对于队列，考虑服务总线或可靠并发队列 (https://docs.microsoft.com/enus/dotnet/api/microsoft.servicefabric.data.collections.preview.ireliableconcurrentqueue-1)。
我们从 2010 年开始使用 Azure，并从我们应用程序的性能和可靠性中受益匪浅。 Azure 提供了很多企业级服务，我认为新的 "Azure Service Fabric" 很棒。
通过阅读文档我无法理解的是将 "old" 云服务迁移到新 Service Fabric 的方法。我们为什么要移民？用于水平扩展和更高的可靠性。
目前我们有一个单实例云服务，它启动了很多子服务。这些子服务非常适合微服务。唯一的问题是这些子服务中的一些是 "runners"，即它们只是在我们的用户数据库上循环并决定操作（服务）是否必须针对特定用户 运行。 考虑到不止一个实例可能 运行 此服务，您将如何迁移这样的服务？
谢谢
首先要记住的是，一旦服务启动，它就会保持 运行ning，并且他的生命周期和正常运行时间由 Service Fabric 控制（例如：如果它崩溃，它会自动重启）。要记住的第二件事是，您最终会同时（在不同的节点上）获得服务 运行ning 的多个实例，因此它们最终会在不同的节点上做完全相同的事情你的集群。
您的第一个反应可能是为每个 运行ner "subservice" 提供一个无状态服务 kind/instance 以保持 运行ning 并利用 RunAsync（https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-reliable-services-advanced-usage ).就个人而言，我不会采用这种方法，因为这可能需要服务之间进行某种同步以防止无用的并发，因为它们独立地做完全相同的事情。
一个更好的方法是让您的 运行ner 服务需要 运行 仅当 "main" 服务作为协调器请求时，您可以一种基于队列的方法，其中 "main" 服务提交任务（消息）由 运行ners 处理，他们同时监听同一个队列，确保最多一个服务实例可以完成任务。
对于队列，考虑服务总线或可靠并发队列 (https://docs.microsoft.com/enus/dotnet/api/microsoft.servicefabric.data.collections.preview.ireliableconcurrentqueue-1)。