4

我正在开发一个包含 WCF 服务的 ASP.NET 应用程序，该服务旨在充当模拟生产环境的测试替身。它代表一个非常复杂的后端，可以通过它的 Web 服务接收订单，然后数小时或数天后发送通知（通过调用其他系统上的 Web 服务）。

这个测试双重应用程序的第一个版本的要求之一是它是无状态的，即没有数据库。

不再参与该项目的原始开发人员实施的设计是：

  1. 通过网络服务接收订单。
  2. 产生一个后台线程
  3. 向客户端返回预设响应
  4. 然后后台线程休眠 5 - 30 秒，发送通知，再次休眠，发送通知，可能重复三到四次，最后在无事可做时终止

线程休眠 5 - 30 秒旨在模拟生产系统的数小时和数天延迟。每个后台线程的生存时间不会超过三分钟。

目前，该设计似乎可以很好地实现其目的。到目前为止，这种方法遇到的唯一问题是，如果发生导致应用程序重新启动的事情（web.config 更改、部署的新 DLL、重新启动 IIS 等），后台线程似乎会被终止，并且任何挂起的通知后台线程永远不会发生。

客户现在决定 5 - 30 秒的延迟太短，通知之间延迟 5 分钟更合适。这意味着后台线程的生命周期可能超过 20 分钟。

我的直觉是，延迟五分钟可能不是这个设计的好主意。我很想看看人们对此有何看法。

随着延迟的增加，这种设计的可靠性如何？是否有人对 ASP.NET 中长时间运行的后台线程有任何经验可以对此发表评论？

4

3 回答 3

3

永远不要像在这个应用程序中那样做这样的“睡觉”；你已经明白为什么会这样了。增加延迟将成倍增加任务未完成的时间，因为时间段越长，应用程序池回收的机会就越大。

可能值得创建一个单独的 Windows 服务，网站/服务可以连接到该服务并启动这些长时间运行的任务。Windows 服务不会像 ASP.NET 服务那样自动回收自身。您可以使用 WCF 来促进 ASP.NET 和 Win 服务之间的通信。

于 2011-06-08T05:43:01.437 回答
1

无论如何，您都需要某种服务来处理这个问题。网站不应该进行后台处理，尤其是 IIS，因为它对应用程序池回收非常激进。

本质上，您需要的是一个假脱机程序或队列。这通常以单独服务或运行的计划任务的形式出现。在 linux 世界中，您将调用这些守护进程或 cron 作业。

如果您使用服务，您将需要能够通过传递工作订单或队列项目（无论您如何称呼它们）与该服务进行交互，并且它将使用您构建的某种通知延迟规则来处理它们。否需要数据库存储，尽管您可能会发现很容易将文件转储到它偶尔拾取的文件夹中。

如果您执行计划任务（可能每分钟运行一次），则很容易将其存储在 sqlite 数据库中，或者再次存储在文件系统中，然后让任务执行它。您可以编写一个简单的命令行应用程序来获取文件并执行其操作。

于 2011-06-08T05:54:11.450 回答
1

如果您可以使用 MSMQ 存储订单然后运行线程来处理队列将是一个好主意。这将确保在升级/重新启动 IIS 服务器时更加可靠。

于 2011-06-08T06:07:57.103 回答