迁移到Azure服务架构 - 架构注意事项

Question

自2010年以来，我们一直在使用Azure，并从我们的应用程序的性能和可靠性中受益匪浅。 Azure提供了很多企业级服务，我认为新的“Azure服务结构”非常棒。

我通过阅读文档无法理解的是将“旧”Cloud Service迁移到新服务结构的方法。我们为什么要迁移？用于水平缩放和更可靠。

目前我们有一个单一实例云服务，它激活了很多子服务。这些子服务非常适合微服务。唯一的问题是这些子服务中的一些是“跑步者”，即他们只是在我们的用户数据库上循环，并决定是否必须为特定用户运行操作（服务）。 考虑到多个实例可能运行此服务，您将如何迁移这样的服务？

感谢

Answer 1

首先要记住的是，一旦在业务启动它继续运行，他的生命周期和正常运行时间由服务控制面料（例如：如果它崩溃，它会自动重新启动它）。要记住的第二件事是，您将最终同时运行多个服务实例（在不同的节点上），因此它们最终会在群集的不同节点上执行完全相同的事情。

你的第一反应可能是每个跑步者的“子服务”有一个无状态的服务种类/实例，它可以继续运行并利用RunAsync（https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-reliable-services-advanced-usage）。就我个人而言，我不会采取这种方法，因为这可能需要在服务之间进行某种同步以防止无用的并发，因为它们独立完成同样的事情。

一个更好的方法是，当你的runner服务需要在“main”服务充当管弦乐队的请求时只运行一次，你可以有一个基于队列的方法，其中“主”服务提交任务（消息）由正在同一队列中同时监听的跑步者处理，确保最大的一个服务实例将完成任务。

对于队列，请考虑服务总线或可靠并发队列（https://docs.microsoft.com/enus/dotnet/api/microsoft.servicefabric.data.collections.preview.ireliableconcurrentqueue-1）。