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

Question

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

ASP .NET 4.0提供了解决此问题的方法.您现在可以将StartMode设置为'AlwaysRunning',如Scott Gu 在此博客文章中所述.某处在这个帖子上的评论,有人问一个有关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服务.现在开发/测试更容易.

必须阅读的是Windows服务的死亡...万岁AppFabric!