作为应用程序体系结构的一部分，我们有3个组件：ASP.Net Web，WCF服务和Windows服务。
ASP.Net Web应用程序调用WCF执行任务。
WCF实习生触发正在运行的Windows服务来执行任务。Windows服务实习生会打开多个线程来执行任务。
开发Windows服务而不仅仅是WCF的原因是由于需要在任务完成过程中打开多个线程。由于WCF只能用作火灾，并且会从Web应用程序中遗忘，因此其他团队决定使用Windows Service。同样（根据其他团队的研究），退出WCF中的任务时不可能关闭所有线程。
这是一个好的架构吗？
同意其他评论者的意见，您可以使用hangfire之类的东西在ASP.NET中完成整个解决方案，以处理后台任务。
我在当前项目中已使用此框架来处理各种类型的长时间运行的任务，并且坚如磐石，特别是与某种客户端通知库（例如，角度烘烤）结合在一起以指示后台任务的状态。
可以调用Windows服务从WCF中执行任务吗？
从技术上讲，这没有什么不对劲的，但是您最好将WCF服务托管在Windows服务中，而不是将它们分开。只是另一个动静部分，没有任何实际收益。
是否可以在不使用Windows服务的情况下构造此应用程序？
看上面。
来自评论：
不幸的是，从asp.net应用程序启动的任务可能会持续10分钟到1小时以上
我们的一些后台任务耗时超过30分钟，尽管没有一项花费一个小时。虽然不能保证IIS辅助线程会徘徊足够长的时间来完成任务，但是hangfire提供了一个铁腕保证，即无意中卸载的任务将重新运行并最终成功。这是自动的，不需要额外的配置。
用户还需要获取任务进度的状态更新。
正如我在原始答案中所说，我们正在通过客户端轮询实时提供状态指示（作业类型，经过的时间，预期的完成时间等）。我们实际上轮询了hangfire数据库（不是推荐的方法，但是对我们来说足够安全），但是您也可以在内存中单击hangfire作业管理器以检索此信息（这是推荐的方法）。
看起来HangFire更像是火与遗忘
Hangfire绝对是一劳永逸的事情，但这就是使它健壮的原因，并且应该是任何后台任务运行程序实现的功能。在我看来，等待某种完成回调事件是棘手且不愉快的。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句