过去我们使用无状态服务基础架构构建了我们的系统，因为我们有一个将项目放入Azure队列的前端API，然后有工作者角色处理这些队列。从理论上讲，这看起来很棒，云应该如何运作。随着我们的队列增长，它将启动我们的应用程序的更多实例，这是单线程的，每个处理一批30个项目。当队列缩小时，它会将它们旋转下来。
然而，这最终没有按预期工作。 Azure仅根据队列中的项目自动缩放工作者，而不是待处理的项目。由于项目可以提前5天放入我们的队列，这给我们留下了大量我们不需要的缩放实例。作为一种解决方案，我们最终只是将我们的实例扩展到我们最多需要的范围，这种方式从整个云体验中脱颖而出。此外，随着我们获得数据突发，我们有时会得到备份。理想情况下，我们希望在几秒钟内处理我们的数据，但这需要几分钟，因为它只能用这种方法同时处理这么多。
由于云服务如何上下移动的性质，这不仅成本高昂，而且当我们需要真正添加资源时，我们不得不等待10多分钟才能使我们的实例启动。这是我们手动观察队列和调整天蓝色实例。我知道我们可以开发第三方应用程序来自动旋转上下，但真正的问题是简单地添加或删除单个实例需要多长时间。
由于我们遇到了云服务的所有限制，我们最终回归到可以处理添加150多个单独线程的单个应用程序，并且每个应用程序都会将进度报告回主UI。对于成本的一小部分，几乎没有系统功率，我们始终在云服务中运行40个实例，随时运行多达150个线程，我们认为适合自动扩展和缩小。我们只是看看在接下来的3分钟内会出现什么，并根据它来扩展我们的线程。
这个单一的应用程序可以完美地扩展和缩小，就像我希望在云中发生一样。我们看到前所未有的性能，我可以一次看到所有线程的状态，而且开销非常低，因为每个线程处理一批30个队列项，每个任务大约需要2-3秒。
现在明显的垮台是我们基本上恢复了旧的思维方式，我们正在使用的云基础设施只不过是一台虚拟机。如果这个应用程序崩溃或计算机重新启动怎么办？当我们需要更多处理能力时会发生什么？我们如何轻松部署运行的单个WinForm应用程序？ （我们使用章鱼部署，它只提供Windows服务）我们如何处理可能在桌面上运行的8种不同的EXE？
我们知道必须有更好的方法，我们可以根据当前的工作负载自动扩展单个线程。此外，它在云中运行，因此我们不受管理VM的限制。
我花了6个小时阅读服务结构，这似乎是朝着正确方向迈出的一大步，但是我仍然找不到涵盖我们的用例的单个文档以及设置它的最佳方法。
如何创建一个系统，根据需要自动扩展单个任务（线程）的实例，并在每个任务完成时，确定它是否应该减速，因为不再需要它？我知道我需要一个父工作器来驱动这些实例，并告诉每个实例是否需要在完成后关闭它们。但是，我找不到像这样的项目的编码/文档的任何示例，它使用azure。
一个很好的用例是电子邮件发件人：
- 我们有一个应用程序可以将电子邮件放入队列中，并附上何时出去的时间表
- 我们有第二个单线程应用程序，可以将接下来的30个项目排入队列，准备就绪，并将它们发送出去
- 现在当有人将25,000个项目添加到队列中时会发生什么？
我们希望电子邮件能够在应有的时候发布，但我们如何扩展
这个单一的，1个线程的应用程序，有多个实例。我们怎么样
然后缩小完成后不再需要的线程？
由于
答案 0 :(得分：1)
您的问题不在于如何扩展基础架构，而在于您如何构建活动工作流程。如果您只希望在特定时间（当它将要到期时）处理队列，而不是在添加它时，您是否考虑过添加作为当前工作负载的辅助队列，而不是排队未来的工作量
然后只需将项目从待处理队列移动到＆＃34;活动＆＃34;你希望它们被消费时排队。此时，您可以依靠实例扩展来消耗活动队列中的工作负载。您用于消耗工作量的平台是您的选择 - 功能，Web作业，批处理等;但是，您可以使用逻辑应用程序来帮助协调worklflow部分并在队列之间移动消息。