关于使用 StartMode=“AlwaysRunning”在 ASP .NET 4 上运行 Windows 服务类型应用程序的想法
通常我会考虑编写一个 Windows 服务来管理不适合托管在 Web 应用程序中的任务。这些类型的任务通常是长时间运行的进程或计划任务。尽管这通常是此类任务的主要方法，但人们已经研究过通过在 Global.asax 公开的 Application_Start 事件中启动多个线程，在 Web 应用程序中运行此类后台进程的方法。这种方法的问题始终是，如果您的 IIS 工作进程终止，那么您的后台线程也会被终止（实际上您的“Windows 服务”将停止，直到收到下一个请求）。
ASP .NET 4.0 为这个问题提供了一个解决方案。您现在可以将 StartMode 设置为“AlwaysRunning”，如下所述 博客文章，作者：Scott Gu。 在这篇文章的评论中，有人询问了有关在 IIS 中托管 Windows 服务类型任务的可行性的问题，因为新功能可确保工作进程始终运行。斯科特提到，它肯定会支持这个场景。除此之外，最近引入了 AppFabric 意味着 Microsoft 本身正在提供简单的挂钩，用于在 Web 应用程序中托管和监视 WCF 和 WF 服务。
对于我们这些曾经编写 Windows 服务来支持 Web 应用程序的人来说，这意味着什么？我们应该采用这种模式吗？有哪些陷阱？据我所知，在 Web 应用程序中托管“Windows 服务”进程有很多好处，最有用的是易于部署。此外，我们实际上可以开始为我们的服务开发简单的用户界面，该界面提供有关运行时发生的情况的信息。
如果我必须走这条路，我认为我不会在面向客户的 Web 应用程序中托管“Windows 服务”类型的功能。我可能会开发一个新的 Web 应用程序项目（就像在 Windows 服务上下文中一样）来托管我的长时间运行/计划任务进程。我想这有几个原因。
- 安全。显示有关正在运行的后台进程的信息的 UI 可能有不同的安全模型。我不想将此 UI 暴露给运营团队以外的任何人。此外，Web 应用程序可以作为具有更高权限集的不同用户运行。
- 维护。如果能够将更改部署到托管后台进程的应用程序而不影响用户使用前端网站，那就太好了。
- 性能。将应用程序与处理用户请求的主站点分开意味着后台线程不会削弱 IIS 处理传入请求队列的能力。此外，如果需要，处理后台任务的应用程序可以部署到单独的服务器上。
我真的很想听听您对这种方法的想法以及我是否应该坚持使用 Windows 服务。我很想尝试这种新方法。
Usually I would look at writing a Windows Service to manage tasks that aren't suited to being hosted in a web application. These types of tasks are usually long running processes or scheduled tasks. Although this is normally the primary approach for these types of tasks, people have looked at ways of running these kinds of background processes in a web application by kicking off a number of threads in the Application_Start event exposed by Global.asax. The problem with this approach has always been that if your IIS worker process dies, then your background thread is killed too (effectively your 'Windows Service' is stopped until the next request is received).
ASP .NET 4.0 offers a solution to this problem. You can now set the StartMode to 'AlwaysRunning' as described in this blog post by Scott Gu. Somewhere in the comments on this post, someone asks a question about the viability of hosting Windows Service type tasks in IIS since the new feature ensures the worker process is always running. Scott mentioned that it would definitely support the scenario. Further to this, the recent introduction of AppFabric means that Microsoft themselves are providing simple hooks for hosting and monitoring WCF and WF services in a web application.
What does this mean for those of us that used to write Windows Services to support our web apps? Should we adopt this model? What are the pitfalls? As far as I can tell, there are a number of benefits to hosting 'Windows Service' processes in a web application, the most useful being the ease of deployment. Furthermore, we can actually start developing simple user interfaces to our services which provide information about what is happening at runtime.
If I had to go this route, I don't think that I would host my 'Windows Service' type functionality in the customer facing web application. I would probably develop a new web application project (much like I would in the Windows Service context) that would host my long running/scheduled task processes. I guess there are few reasons for this.
- Security. There may be a different security model for the UI displaying information about the running background processes. I would not want to expose this UI to anyone else but the ops team. Also, the web application may run as a different user which has an elevated set of permissions.
- Maintenance. It would be great to be able to deploy changes to the application hosting the background processes without impacting on user's using the front end website.
- Performance. Having the application separated from the main site processing user requests means that background threads will not diminish IIS's capability to handle the incoming request queue. Furthermore, the application processing the background tasks could be deployed to a separate server if required.
I would be really interested to hear your thoughts on this approach and whether I should be sticking with Windows Services. I am very tempted to try this new approach.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我认为这是一个关键场景，您可以从 Windows 服务转向使用持续运行的网站。
标准开发答案：取决于；）
我发现的一个问题是 IIS 依赖性。如果您需要在用户计算机上运行某项服务，那么仅仅为了运行我的服务而要求他们安装 IIS 我会感到不舒服。在这里我认为传统模式效果更好。
监控和跟踪是主要问题，但正如您也指出的那样，这是由 AppFabric 解决的。它甚至比您从 Window Service 获得的服务更好。但是，您添加了另一个依赖项，该依赖项也需要 .NET 4.0 和相对较新版本的 Windows。我在这里也可能是错的，但我的理解是客户端操作系统的生产中不支持 AppFabric。这可能会带来额外的麻烦。
您也将失去连续网站模型中的暂停功能。
最后，IIS 杀死不活动的应用程序池并不是应用程序池回收的唯一方法。例如，编辑 web.config 文件会导致这种情况，这可能不是理想的情况。
我还认为开发更容易 - 过去我有一个控制台应用程序和一个 Windows 服务，因此我可以使用控制台应用程序在我的计算机上进行开发/测试，然后在它退出时将其更改为 Windows 服务。现在开发/测试变得更加容易。
必须阅读的内容是 Windows 服务消亡...AppFabric 万岁！
I think this a key scenario where you could be move away from a Windows service to using the continous running web site.
Standard development answer: Depends ;)
One issue I can see is the IIS dependency. If you need a service to run on a users machine I would not feel comfortable about asking them to install IIS just to run my service. Here I think the traditional model works better.
Monitoring and tracking are major issues, but as you also point out this is solved by AppFabric. It is even better than what you get from the Window Service. However you have added another dependency which also will require .NET 4.0 and a relatively new version of Windows. I could also be wrong here, but my understanding is that AppFabric is not supported in production on client OS's. Which could bring in additional headaches.
You will lose pause functionality in the continuous web site model too.
Finally IIS killing inactive app-pools isn't the only way an app pool can recycle. Editing a web.config file causes it for instance, which may not be an ideal situation.
I also think development is much easier - in the past I have had a console app and a windows service so I can dev/test on my machine using the console app and then change it to a windows service when it goes out. Now dev/test is MUCH easier.
A must read for this is Death to Windows Services...Long Live AppFabric!
我发现，没有关闭事件。当网站启动时，您有 AppStart（不是 global.asax，因为那只是 HTTP），但您无法处理关闭，这可能意味着处置成为一个问题。
One I found, no shutdown event. You have AppStart when the web site starts (not global.asax because that is HTTP only) but you have no way to handle shutdown which could mean disposing becomes an issue.
我建议坚持使用 Windows 服务。问题出在你的2号上。
如果不重新启动整个网站，您将无法更新网站的服务部分。
I would suggest sticking with a windows service. The issue is with your number 2.
You won't be able to update service part of web site without restarting whole web site.