Azure -基于挂起项扩展单线程应用程序的最佳实践

Question

在过去，我们使用无状态服务基础设施构建我们的系统，因为我们有一个将项目放入Azure队列的前端API，然后有工作者角色处理这些队列。从理论上讲，这看起来很棒，以及云应该如何工作。随着队列的增长，我们的应用程序会有更多的实例，它是单线程的，每个实例处理一批30个项目。随着队列的缩小，它们的速度会变慢。

然而，这最终并没有像预期的那样工作。Azure仅基于队列中的项目自动缩放工作进程，而不是挂起的项目。由于项目最多可以提前5天放入我们的队列中，这给我们留下了大量不需要的可伸缩实例。作为一种解决方案，我们最终只是将我们的实例扩展到我们最需要的，这在某种程度上从整个云体验中消失了。此外，当我们获得突发数据时，我们有时会被备份。理想情况下，我们希望在几秒钟内处理我们的数据，但这需要几分钟的时间，因为使用这种方法一次只能处理这么多。

由于云服务旋转的性质，这不仅是昂贵的，而且当我们需要真正添加资源时，我们必须等待10+分钟才能让我们的实例旋转。这就是我们手动观察队列并调整azure中的实例。我知道我们可以开发一个第三方应用程序来自动上下旋转，但真正的问题是需要多长时间来简单地添加或删除单个实例。

由于我们在使用云服务时遇到的所有限制，我们最终求助于可以处理添加150+单独线程的单个应用程序，并且每个线程都将进度报告回主UI。只需很少的成本，而且几乎没有系统电源，我们就从一直在云服务中运行40个实例，到在任何时候都有多达150个线程运行，并根据我们认为合适的情况自动扩展和缩减。我们只是简单地看看接下来3分钟会发生什么，并根据这一点扩展我们的线程。

就像我希望在云中发生的那样，这个简单的应用程序可以完美地扩展和缩小。我们看到了前所未有的性能，我可以一次看到所有线程的状态，而且开销非常低，因为每个线程处理一批30个队列项目，每个任务大约需要2-3秒。

现在明显的缺点是我们基本上回到了旧的思维方式，我们正在利用的云基础设施只不过是一个虚拟机。如果这个应用程序崩溃或计算机重启怎么办？当我们需要更多的处理能力时会发生什么？我们如何轻松部署运行的单个WinForm应用程序？(我们使用octopus deploy，它只做windows服务)我们如何处理在桌面上运行的8种不同的EXE？

我们知道一定有更好的方法，我们可以根据当前的工作负载自动扩展单个线程。此外，它在云中运行，因此我们不会受到管理虚拟机的限制。

我花了6个小时阅读service fabric，这似乎是朝着正确方向迈出的很好的一步，但是我仍然找不到一个涵盖我们用例的文档以及设置它的最佳方法。

如何让系统根据需要自动缩放单个任务(线程)的实例，并在每个任务完成时决定是否应该因为不再需要它而降速？我知道我需要一个父worker来启动这些实例，并在完成时告诉每个实例是否需要关闭。然而，我找不到任何使用azure的这样的项目的编码/文档示例。

一个很好的用例是电子邮件发件人：

• 我们有一个应用程序，可以将电子邮件放入队列中，并有一个何时发送的时间表。
• 我们还有第二个单线程应用程序，它可以提取队列中的下30个项目，准备就绪，并将它们发送出去。
• 现在，如果有人现在将25,000个项目添加到队列中，会发生什么？我们希望电子邮件在应该发送的时候发出，但是我们如何扩展这个单线程的应用程序，使其具有多个实例。一旦完成，我们如何缩减不再需要的线程？

谢谢

Answer 1

您的问题不在于如何扩展基础架构，而在于如何构建您的活动工作流。如果您只希望队列在特定时间(即将到期时)处理，而不是在添加时处理，您是否考虑过添加一个作为当前工作负载的辅助队列，而不是添加排队的未来工作负载？

然后，当您想要使用项目时，只需将项目从挂起队列移动到“活动”队列即可。此时，您可以依靠实例扩展来消耗活动队列中的工作负载。你用来消耗工作负载的平台就是你的选择--功能、web作业、批处理等等；但是，你可以使用逻辑应用程序来帮助协调工作流部件和在队列之间移动消息。