使用StartMode =“AlwaysRunning”在ASP .NET 4上运行Windows服务类型应用程序的想法

Question

通常我会考虑编写Windows服务来管理不适合托管在Web应用程序中的任务。这些类型的任务通常是长时间运行的进程或计划任务。虽然这通常是这些类型任务的主要方法，但people已经研究了在Web应用程序中运行这些后台进程的方法，方法是在Global.asax公开的Application_Start事件中启动一些线程。这种方法的问题一直是，如果你的IIS工作进程死了，那么你的后台线程也会被杀死（实际上你的'Windows服务'会在收到下一个请求之前停止）。

ASP .NET 4.0提供了解决此问题的方法。您现在可以将StartMode设置为'AlwaysRunning'，如Scott Gu所述blog post中所述。 Somewhere在这篇文章的评论中，有人询问有关在IIS中托管Windows服务类型任务的可行性的问题，因为新功能可确保工作进程始终在运行。斯科特提到它肯定会支持这种情况。除此之外，最近引入AppFabric意味着Microsoft本身提供了用于在Web应用程序中托管和监视WCF和WF服务的简单钩子。

对于我们这些曾经编写Windows服务来支持我们的网络应用程序的人来说，这意味着什么？我们应该采用这种模式吗？有什么陷阱？据我所知，在Web应用程序中托管“Windows服务”流程有很多好处，最有用的是易于部署。此外，我们实际上可以开始为我们的服务开发简单的用户界面，这些界面提供有关运行时发生的事情的信息。

如果我必须走这条路，我认为我不会在面向客户的Web应用程序中托管我的“Windows服务”类型功能。我可能会开发一个新的Web应用程序项目（很像我将在Windows服务上下文中），它将托管我的长时间运行/计划任务进程。我想这有几个原因。

1. 安全即可。 UI可能有不同的安全模型，显示有关正在运行的后台进程的信息。除了操作团队之外，我不想将此UI公开给任何其他人。此外，Web应用程序可以作为具有提升权限集的其他用户运行。
2. 维护即可。如果能够将更改部署到托管后台进程的应用程序而不影响用户使用前端网站，那将会很棒。
3. 的效果即可。将应用程序与主站点处理用户请求分开意味着后台线程不会降低IIS处理传入请求队列的能力。此外，如果需要，可以将处理后台任务的应用程序部署到单独的服务器上。

我真的很想听听您对这种方法的看法以及我是否应该坚持使用Windows服务。我非常想尝试这种新方法。

Answer 1

  

对于我们这些曾经编写Windows服务以支持我们的网络应用程序的人来说，这意味着什么？

我认为这是一个关键场景，您可以从Windows服务转移到使用连续运行的网站。

  

我们应该采用这种模式吗？

标准开发答案：取决于;）

  

有哪些陷阱？

我可以看到的一个问题是IIS依赖项。如果您需要在用户计算机上运行服务，我会觉得要让他们安装IIS只是为了运行我的服务。在这里，我认为传统模式效果更好。

监控和跟踪是主要问题，但您也指出这是由AppFabric解决的。它甚至比从Window Service获得的更好。但是，您添加了另一个依赖项，它还需要.NET 4.0和相对较新版本的Windows。我在这里也可能是错的，但我的理解是在客户端操作系统的生产中不支持AppFabric。这可能带来额外的麻烦。

您也将失去连续网站模型中的暂停功能。

最后，IIS杀死非活动应用程序池并不是应用程序池可以回收的唯一方式。例如，编辑web.config文件会导致它，这可能不是一个理想的情况。

  

最有用的是易于部署。

我也认为开发更容易 - 过去我有一个控制台应用程序和一个Windows服务，所以我可以使用控制台应用程序在我的机器上开发/测试，然后在外出时将其更改为Windows服务。现在开发/测试更容易。

必须阅读的内容为Death to Windows Services...Long Live AppFabric!

Answer 2

  

有哪些陷阱？

我找到一个，没有关机事件。您在网站启动时有AppStart（不是global.asax，因为它只是HTTP），但您无法处理关闭，这可能意味着处理成为一个问题。

Answer 3

我建议坚持使用Windows服务。问题在于你的2号。 如果不重新启动整个网站，您将无法更新网站的服务部分。