ASP.Net webservice/asmx/ashx/whatever编程
我需要构建一个代理（可能是一个错误的描述），它从第 3 方接收 XML 文件，保存它，将其发送到另一个第 3 方，获取响应并将其传递回原始第 3 方。我们将整个过程称为“单元”。
我应该使用网络服务吗？通用处理程序？还有别的事吗？
我可能必须每秒执行 20 个“单元”，但我知道每个“单元”可能会持续 30 秒到一分钟，所以实际上，我的意思是我需要能够让 1200 个这些“单元”在同时，在我上面描述的过程的所有不同阶段。
就文件保存而言，我最终想将其放入数据库中，但我想写入文件比实际将数据保存到数据库中更快，所以我将有另一个几乎不存在的过程由于时间紧迫，这会抓取文件并在方便时将它们插入数据库。
“应用程序”仅包含 1 个页面，并且将在 SSL 下运行。这可能是在任何给定时间该服务器上唯一确保这个小进程不是瓶颈的事情。
.Net 中什么是解决此问题的好（快速且可扩展）方法？就硬件而言，我对所需的东西没有任何有效的限制——因此，如果它能保证没有瓶颈，我可以获得一台尖叫的机器。
I need to build a proxy (maybe a bad description) that receives an XML file from a 3rd party, saves it, sends it on to another 3rd party, gets the response back and passes that back to the original 3rd party. Let's call that entire process a "unit".
Should I use a webservice? A Generic Handler? Something else?
I might have to do 20 "units" per second, but I know that each "unit" may span 30 seconds to a minute each, so really, I mean that I need to be able to have 1200 of these "units" running at the same time, in all varying stages of the process that I described above.
As far as the file saving goes, I eventually want to put this into a database, but I would imagine that writing the file is quicker than actually saving the data into a database, so I'll just have another process that isn't nearly as time critical as this grab the files and insert them into the DB at its own convenience.
The "app" will only consist of 1 page and it will be running under SSL. This will likely be the only thing on this server at any given time to ensure that this little process is not a bottleneck.
What in .Net would be a good (fast and scalable) way to go about this? I don't have any effective limit on what I would need as far as hardware goes -- so I can get a screaming machine if it would guarantee no bottlenecks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
由于 Web 服务基于 XML，因此您需要考虑这样一个事实：最终可能会出现“XML 中的 XML”。但除此之外，我想说使用网络服务是一个很好的方法。主要是因为它兼容、易于使用且易于理解（对于未来的维护人员）。
然而，还有一些使用较少 CPU/内存/带宽的替代方案。 WCF 提供了几种模型来解决这个问题，无论是在 IIS 下运行还是在独立进程和传输类型方面。
就我个人而言，我很喜欢通过 TCP 进行简单的老式二进制传输。 REST 可能是一种方法，因为它是兼容的（例如前端代理/缓存），并且本质上为您提供了很少开销的二进制传输。
我还喜欢将脏活儿留给 IIS，因此我避免使用独立的 WCF 应用程序。我认为 IIS 比我能轻松做到的更快、更稳定。
也许我关于高并发负载的问题可以有帮助。
Since webservices are based on XML you need to consider the fact that you could end up with "XML inside XML". But part from that I'd say using webservices is a good way to go. Mostly because it is compatible, easy to use and easy to understand (for future maintainers).
There are however alternatives that use less CPU/memory/bandwith. WCF provides several models to solve this both in regard to running under IIS or stand-alone process and transfer type.
Personally I'm a fan of plain old binary transfer through TCP. REST could be one way to go as it is compatible (frontend proxy/caching for instance) and essentially gives you a binary transfer with little overhead.
I also like to leave the dirty work to IIS, so I avoid stand-alone WCF apps. I assume IIS is faster and more stable than what I can do easily.
Maybe my question on high concurrent load can be of help.
我会编写一个 WCF 服务，使用 REST 来简化其 URL，并将 WCF 服务设置为单例运行，这样您的内存就不会失控。
关于 WCF 的好文章： http://www.c-sharpcorner.com/UploadFile/sridhar_subra /116/
I would write a WCF service, use REST to simplify it's URLs, and set the WCF service to run as a singleton so that your memory doesn't get out of control.
Good article on WCF: http://www.c-sharpcorner.com/UploadFile/sridhar_subra/116/