客戶端和內部應用程序設計之間的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％最終會超時，假設你的服務器本身不會在重量下崩潰。