我需要构建一个代理（可能是一个糟糕的描述），它从第三方接收XML文件，保存它，将其发送给另一个第三方，获得响应并将其传递回原始第三方。让我们将整个过程称为“单位”。
我应该使用网络服务吗？通用处理程序？还有别的吗？
我可能每秒必须做20个“单位”，但我知道每个“单位”可能每个跨越30秒到1分钟，所以我的意思是我需要能够拥有1200个“单位” “在我上述过程的所有不同阶段同时运行。
就文件保存而言，我最终想把它放到一个数据库中，但我认为编写文件比将数据保存到数据库中更快，所以我只需要另一个进程几乎和时间一样重要，因为它抓住文件并在方便的时候将它们插入数据库。
“app”只包含1个页面，它将在SSL下运行。这可能是在任何给定时间此服务器上唯一确保这个小过程不是瓶颈的事情。
.Net中的内容是一种好的（快速且可扩展的）方式吗？就硬件而言，我对所需要的东西没有任何有效的限制 - 所以如果它能保证没有瓶颈，我就可以得到一台尖叫的机器。
答案 0 :(得分：2)
我会写一个WCF服务，使用REST来简化它的URL，并将WCF服务设置为单独运行，这样你的内存就不会失控。
关于WCF的好文章：http://www.c-sharpcorner.com/UploadFile/sridhar_subra/116/
答案 1 :(得分：2)
由于webservices基于XML，因此您需要考虑最终可能会出现“XML in XML”这一事实。但部分原因是我说使用webservices是一个很好的方法。主要是因为它兼容，易于使用且易于理解（对于未来的维护者）。
然而，有一些替代方案使用较少的CPU /内存/带宽。 WCF提供了几种模型来解决这个问题，无论是在IIS下运行还是独立进程和传输类型。
就个人而言，我是通过TCP进行普通旧二进制传输的粉丝。 REST可能是一种可行的方式，因为它兼容（例如前端代理/缓存），并且本质上为您提供了一个只需很少开销的二进制传输。
我也想把脏工作留给IIS，所以我避免使用独立的WCF应用程序。我认为IIS比我能做的更快更稳定。
也许我对high concurrent load的问题可以提供帮助。