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

Question

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

IE：

客户端---1）请求---> Web服务

客户端

我正在尝试设计 Web 服务的实现，并试图思考如何实现将接受请求的机制，一直保持到内部应用程序发出数据请求并且 Web 服务等待来自内部应用程序的响应。

我主要担心的是：

1) 如果在内部应用程序发出请求之前有数千个请求进来了怎么办？

2) 如果内部应用程序死掉并且大量请求建立怎么办？ （我需要让这些请求超时）

3) 如何将初始请求与客户端和内部应用程序的响应连接起来？

4) 客户端将等待响应。

WCF 消息队列在这种情况下会有所帮助吗？ Web 服务是否能够在内部管理消息队列，例如，当消息进入时，Web 服务会将消息添加到队列中，类似地，当内部应用程序发出请求时，Web 服务会从顶部抓取消息队列并将其传递给内部应用程序并等待内部应用程序的响应并将其传递回客户端？

这可能吗？

如果同时有2000个客户端请求进来，因为客户端会同步等待响应，上面的场景可以吗？我能否将原始请求与从内部应用程序线程返回的响应进行匹配，以将响应提供回客户端？

消息队列方法看起来是不是有点矫枉过正？我可以将请求保存在一些静态字典中吗？

您还有其他建议吗？

Answer 1

首先，坦率地说，轮询式架构对于实时请求处理来说是非常错误的。如果完全有可能将请求直接转发给将要处理它们的应用程序，那将是无限可取的。你让自己面临一大堆额外的问题，而且你甚至将最佳情况的响应时间限制在“几秒钟”之内，这太糟糕了。

但是。假设您无法对架构做任何事情，将消息排队以供内部应用程序检索不是问题。内存中的队列结构可以很好地处理这个问题（只需将队列的大小限制为几千，如果它填满则返回错误）。您真正的瓶颈将是 Web 服务上打开的请求数。如果每个请求的最小打开时间为“几秒钟”，我只是看不到指定的体系结构如何能够每秒处理数千个请求。服务器的设计不是为了保持这么多请求的开放。那些能够每秒处理数千个请求的人会在几毫秒内响应每个请求，然后将其清除。如果每个请求都打开了几秒钟，它会拖垮你的服务器 - 请求将排队，其中 90% 的请求最终会超时，前提是你的服务器本身不会在重压下崩溃。