ASP.Net架构解决方案/建议

Question

我们的应用程序架构包括三个组件：ASP.Net Web、WCF服务和Windows服务。

1. ASP.Net Web应用程序调用WCF执行任务。
2. WCF内部触发正在运行的Windows服务执行任务。Windows服务内部打开多个线程来执行任务。
3. Windows服务使用进度状态更新数据库，并且Web应用程序读取状态更新以供用户查看。 Web应用程序由一个独立的团队开发，而其他团队负责WCF和Windows服务。

开发Windows服务而不仅仅使用WCF的原因是需要在完成任务时打开多个线程。由于WCF只能作为Web应用程序中的fire and forget使用，所以其他团队决定使用Windows服务。另外，根据其他团队的研究，退出WCF任务时不可能关闭所有线程。

1. 这是一个好的架构吗？
2. 从WCF调用Windows服务执行任务可以吗？
3. 是否有可能在不使用Windows服务的情况下设计此应用程序？

- bp581

---

不，这太复杂了。你可以在ASP.NET中完成所有这些事情。 - Aydin

怎么做呢？将ASP.NET变成一个多线程应用程序不会产生复杂性吗？同时，我们希望在两个团队之间分担职责，因为两个团队都对其他任务了解有限。 - bp581

你为什么认为WCF不能处理线程？ - John Saunders

您可以有效地管理ASP .NET应用程序中的线程，并且为了跨团队共享，您可以使用组件和库。我认为这两个因素不会影响您的决定，如果我处于您的情况下。话虽如此，还有其他因素。如果任务运行时间长且密集，则可能会影响运行ASP .NET应用程序的Web服务器的性能。如果在这种情况下我想要一个“fire and forget”，同时将工作负载移动到另一台机器上，我会考虑使用队列，例如RabbitMQ。Web应用程序添加到队列中，工作程序读取它。 - RVid

Answer 1

这是一个好的架构吗？

同意其他评论者的观点，你可以使用像 hangfire这样的ASP.NET解决方案来处理后台任务。

我在我的当前项目中使用了这个框架来处理不同类型的长时间运行的任务，它非常稳定，特别是与一些客户端通知库（如 angular toasty）结合使用，以指示后台任务的状态。

从WCF调用Windows服务执行任务是否可以？

从技术上讲，这没有什么不对的地方，但最好将WCF服务托管在Windows服务中，而不是分开使用。这只是为了增加另一个移动部件，没有任何真正的收益。

是否可以在不使用Windows服务的情况下设计此应用程序？

请参见上面的内容。

从评论中：

不幸的是，从asp.net应用程序启动的任务可能需要10分钟到1小时以上的时间。

一些后台任务需要超过30分钟的时间，但目前还没有一个任务需要一个小时。虽然无法保证IIS工作线程会停留足够长的时间来完成任务，但Hangfire提供了一个铁杆保证：无意中卸载的任务将被重新运行并最终成功。这是自动的，不需要额外的配置。

此外，用户需要获取任务进度的状态更新。就像我在原始答案中所说的那样，我们通过客户端轮询实时提供状态指示（作业类型、经过的时间、预期完成时间等）。我们实际上轮询了hangfire数据库（这不是推荐的方法，但对我们来说足够安全），但您也可以在内存中访问hangfire作业管理器以检索此信息（这是推荐的方法）。

看起来HangFire更像是“发射并忘记”。Hangfire确实是“发射并忘记”，但这正是它的强大之处，并且应该是任何后台任务运行器实现的特点。在我的看法中，等待某种完成回调事件是棘手和不愉快的。

- tom redfern

---

刚快速浏览了一下 Hangfire …… 看起来不错。不幸的是，从 asp.net 应用程序启动的任务可能需要 10 分钟到 1 个小时以上的时间。用户还需要获取任务进度的状态更新。看起来 HangFire 更像是“发射并忘记”。因此，我们考虑让 Windows 服务执行长时间运行的任务，并在进度上更新数据库，以便 asp.net web 应用程序可以从中读取。 - bp581

@bp581 - 请查看我对你的回复所做的修改。 - tom redfern