用于批处理的Azure Windows服务

Question

我想构建与“Windows服务”等效的Azure PaaS。我当然可以创建一个VM并部署Windows服务，但我正在寻找可扩展/ PaaS方式来实现这一点。基本上我的应用程序是监视队列的后端服务（例如Azure Service Bus），当队列中有消息进入时，它将执行一堆处理逻辑（处理逻辑，访问数据库，调用其他Web服务，排队）其他过程等）。某些服务可能需要执行更多“高级”操作，例如创建子应用程序域，将临时文件写入磁盘等。

我应该寻找什么样的Azure解决方案来满足这种需求？

感觉Azure在过去几年中已经发展了很多，当我试图找出满足我需求的最佳服务时，我感到很困惑。一些项目类型现在看起来已经过时，但仍然有很多旧的文档/博客。我看到了对WebJobs，工作者角色，逻辑应用程序和函数的引用。在构建Azure服务方面更有经验的人能告诉我应该考虑哪些技术来满足我的需求吗？

我觉得这应该是一种显而易见的常见需求，但也许我只是使用了错误的搜索词而且我并没有真正找到很多符合我的确切需求或信息的信息我发现从2011年开始，我担心从那时起景观发生了很大变化。

Answer 1

您可以选择WebJobs，Logic应用程序，Service Fabric或功能，这取决于您需要对您正在部署的代码进行多少控制。工作者角色是云服务术语，虽然它们仍然受支持，但通常不推荐使用，因为列出的其他服务的部署，可扩展性和管理要好得多。

Web作业和函数都使用相同的WebJobs SDK为您提供从队列，blob或调度执行中触发的大量支持。它们都在应用服务计划内运行（并与之一起扩展），但功能是无服务器＆＃34;因为您不需要查看或管理Web应用程序服务实例，只需部署源代码 - 它将在部署时编译。

Service Fabric是一个完全不同的野兽，提供弹性和低延迟状态（数据）复制，但也可以作为无状态批处理执行的选项。它创建了一个虚拟机节点群集，可以为您管理弹性和部署，还有更多需要理解和管理的东西，但它对于大规模有状态服务这样的事情来说非常棒。

逻辑应用程序具有不同的执行/收费模式，并且可以按需扩展，但更重要的是协调工作流程并将组件连接在一起而不是实际执行操作。 IE浏览器。处理队列中的数据可能是一个组件，需要在某个地方运行 - 可能在API应用程序或您还要托管的Azure功能中。

Answer 2

逻辑应用程序专为您描述的确切方案而设计。

您应该能够创建一个在Service Bus队列中触发新消息的逻辑应用程序。

然后，Logic Apps本身支持与SQL / Queue / REST的交互，甚至是本地文件系统，XML验证，X12 / AS2 / EDI，以及内置函数，如解析JSON / XML，条件，循环，对于Logic Apps目前不支持的更高级操作，您可以使用Azure功能扩展Logic Apps。