现在我正在考虑如何组织系统的架构。该系统将由网站组成，用户可以在其中上传一些文档，然后将其处理回来，以及一些后台守护程序，其中包含应处理提供的文档的任务队列。
我的问题是：我是否应该将上面告诉你的守护进程实现为仅具有命名管道的 WCF 服务（不需要网络访问该服务）？
对此有任何建议/提示/建议吗？
用户可以提供的数据只是一堆 XML 文件。ASP.NET 网站将公开获取此 XML 文件的功能，然后应该能够以某种方式将它们传递给守护进程。
您能否指出我有关该主题的一些文章。提前致谢！
几个小时后，人们在这里发现了 MSMQ，我认为该技术更多的是用于分布式体系结构（处理节点位于不同的机器上，并且通过网络在不同的计算机之间交换消息）。
目前不需要分离到独立的机器。将只有在作为 ASP.NET 网站和一些处理程序的机器上。
使用MSMQ有必要吗？
当我在这里使用 .NET Framework 时，请建议只提供与 .NET 兼容的内容。这里真的没有任何选择。
我设计了类似的东西。我们使用 WCF 服务作为连接点，然后使用 RabbitMQ 对消息进行排队。然后，一个单独的服务处理队列中的项目，当任务完成时发送异步回调，从而完成 WCF 调用（WCF 有许多内置功能来处理这个问题）
您可以在每一侧设置超时，或者您甚至可以选择断开 WCF 连接并使用异步回调来通知用户“处理已完成”我在 RabbitMQ 上的运气比 MSMQ 好得多，仅供参考。
我没有任何链接给你，因为这是我们的团队提出的并且运行良好（1000 TPS 和 4 个服务器池，100% 无状态） - 只是一个想法。
如果您的部署将在单个服务器上，那么您对 WCF 服务的最初想法可能是可行的方法 - 请参阅MSDN，了解有关在 IIS 或 Windows 服务中托管的讨论。
正如@JeffWatkins 所说，调用服务时遵循的一个很好的模式是简单地将需要处理的文件在磁盘上的位置传递给它。这在处理大文件时会更有效率。
我认为这里采用的精确方法将取决于您从用户那里收到的文件的性质。对于非常小的文件，您可能会发现将它们从您的网站流式传输到您的服务更有效，这样它们就不会接触磁盘。在这种情况下，您的服务将公开一个在处理小文件时使用的附加方法。
编辑
引入可以流式传输文件的条件可能是一个好主意，但是对您进行一些测试会很有价值，这样您就可以弄清楚：
我的回答是基于您正在部署到单台机器的假设。如果您想要更具可扩展性的东西，那么是的，使用 MSMQ 将是扩展应用程序的好方法。
有关构建 WCF/MSMQ 演示应用程序的一些示例代码，请参阅MSDN 。
我会认真看待 ServiceStack。此功能是内置的，您只需要做最少的编程。此外，ServiceStack 的架构非常好，如果您遇到任何问题，也很容易调试。
https://github.com/ServiceStack/ServiceStack/wiki/Messaging-and-redis
在相关说明中，我的公司使用基于 Web 的 REST api 前端（REST 服务使用 ServiceStack）进行了大量异步后台处理。我们确实使用了多台机器并实现了 RabbitMQ 后端；但是，RabbitMQ .NET 库的设计非常糟糕并且不必要地繁琐。我对核心类进行了重新设计以解决此问题，但由于我们尚未将项目发布到生产环境，因此无法将它们发布到社区。
看看http://www.devx.com/dotnet/Article/27560
它有点过时，但可以为您提供一个良好的开端和基本的理解。