客户端和内部应用程序设计之间的Web服务中介

Question

我正在创建一个wcf web服务，它将接受许多连续的请求，web服务将需要保持这些请求，直到内部应用程序（这将轮询Web服务每隔几秒钟）将向Web服务发出请求，以确定是否存在任何请求，如果存在则检索它们。然后内部应用程序会将响应发送回Web服务，该服务会将响应传递回初始调用者。

IE：

客户端--- 1）请求---> Web服务< --- 2）请求---内部应用程序

客户< --4）响应---网络服务< --- 3）响应---内部应用程序

我试图设计Web服务的实现，并试图想办法来实现接受请求的机制，坚持下去直到内部应用程序发出数据请求并且web服务等待来自内部的响应l应用程序。

我的主要问题是：

1）如果成千上万的请求进来的内部应用程序发出请求之前，又该如何进行？

2）如果内部应用程序死亡和大量请求建立起来怎么办？ （我将需要不得不超时这些请求）

3）我如何连接初始请求与客户端和内部应用程序的响应？

4）客户将等待回复。

在这种情况下WCF消息队列会有帮助吗？ Web服务是否可以在内部管理Message Queue，如在Web服务中发送消息时将消息添加到队列中一样，当内部应用程序发出请求时，Web服务从顶部抓取消息队列并将其传递给内部应用程序并等待来自内部应用程序的响应并将其传回给客户端？

这是可能的吗？

如果2000个客户端请求同时进入，由于客户端会同步等待响应，上述场景会起作用吗？我能否将原始请求与来自内部应用程序线程的响应进行匹配，以将响应提供给客户端？

消息队列方法看起来是否过分？我可以在一些静态字典中保存请求吗？

您有任何其他建议吗？

Answer 1

坦率地说，首先，轮询式体系结构对于实时请求处理听起来非常错误。如果完全可以将请求直接转发给将要处理它们的应用程序，那将是无限可取的。你将面临一系列其他问题，而且你甚至会将最佳情况下的响应时间限制在“几秒钟”，这很糟糕。

但是。假设你无法对体系结构做任何事情，排队消息以供内部应用程序检索不是问题。内存中的队列结构可以处理这种情况（只需将队列的大小限制为几千，并在填满时返回错误）。您真正的瓶颈将是Web服务上打开请求的数量。如果每个请求的开放时间为“几秒”，则指定架构将无法处理数千次请求/秒。服务器的设计并不是为了保持许多请求。那些能够处理数千次请求/秒的数据通过在几毫秒内响应每个请求来完成，然后将其清除。如果每个请求都打开了几秒钟，那么就会弄脏你的服务器 - 请求将排队等待，其中90％最终会超时，假设你的服务器本身不会在重量下崩溃。