我想构建相当于“Windows 服务”的 Azure PaaS。我当然可以创建虚拟机并部署 Windows 服务，但我正在寻找可扩展/PaaS 方法来执行此操作。本质上，我的应用程序是一个后端服务，用于监视队列(例如 Azure 服务总线)，当消息进入队列时，它将执行一堆处理逻辑(处理逻辑、访问数据库、调用其他 Web 服务、排队)其他流程等)。某些服务可能需要执行一些更“高级”的操作，例如创建子应用程序域、将临时文件写入磁盘等。
我应该寻找什么样的 Azure 解决方案来满足这一需求？
感觉 Azure 在过去几年里已经发展了很多，当我试图找出最好的服务来满足我的需求时，我感到很困惑。一些项目类型现在似乎已经过时，但仍然有很多旧的文档/博客。我看到了对 WebJobs、Worker Roles、Logic Apps 和 Functions 的引用。在构建 Azure 服务方面更有经验的人可以告诉我应该考虑哪些技术来满足我的需求吗？
我觉得这应该是一种显而易见的常见需求，但也许我只是使用了错误的搜索词，并且我并没有真正找到很多似乎符合我的确切需求的信息，或者信息我确实找到了 2011 年的数据，我担心自那以后情况发生了很大变化。
最佳答案
正如您所说，您可以选择 - WebJobs、逻辑应用程序、Service Fabric 或 Functions，这取决于您需要或想要对正在部署的代码进行多少控制。辅助角色是一个云服务术语，虽然仍然受支持，但通常不推荐，因为列出的其他服务的部署、可扩展性和管理要好得多。
Web 作业和函数都使用相同的 WebJobs SDK 为您提供对队列、blob 或调度执行触发的大量支持。它们都在应用程序服务计划内运行(并随其扩展)，但 Functions 是“无服务器”的，因为您不需要查看或管理 Web 应用程序服务实例，并且只需部署源代码 - 它将在部署。
Service Fabric 完全是一个不同的野兽，它提供弹性和低延迟状态(数据)复制，但也可以是无状态批处理执行的一个选项。它在幕后创建了一个虚拟机节点集群，它将为您管理弹性和部署，还有更多需要理解和管理的内容，但它对于大规模有状态服务之类的事情非常有用。
逻辑应用程序具有不同的执行/计费模型，并且将按需扩展，但它更多的是用于编排工作流程和将组件连接在一起，而不是实际执行操作。 IE。处理队列中的数据可能是一个组件，它需要在某个地方运行 - 可能在 API 应用程序或您同时托管的 Azure 函数中。
关于.net - 用于批处理的 Azure Windows 服务，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/41134212/