17

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

ASP .NET 4.0 为这个问题提供了一个解决方案。您现在可以按照Scott Gu的这篇博文中的说明将 StartMode 设置为“AlwaysRunning”。在这篇文章的评论中，有人问了一个关于在 IIS 中托管 Windows 服务类型任务的可行性的问题，因为新功能确保工作进程始终运行。斯科特提到它肯定会支持这种情况。此外，最近推出的AppFabric意味着 Microsoft 自己正在提供简单的挂钩，用于在 Web 应用程序中托管和监视 WCF 和 WF 服务。

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

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

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

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

4

3 回答 3

5

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

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

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

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

有哪些陷阱？

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

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

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

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

最有用的是易于部署。

我还认为开发要容易得多 - 过去我有一个控制台应用程序和一个 Windows 服务，因此我可以使用控制台应用程序在我的机器上进行开发/测试，然后在它退出时将其更改为 Windows 服务。现在开发/测试要容易得多。

必须阅读的是Windows 服务的死亡……AppFabric 万岁！

于 2010-09-16T13:13:31.280 回答
3

有哪些陷阱？

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

于 2010-09-20T10:07:25.243 回答
1

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

于 2010-09-14T17:03:05.573 回答