посредничество веб-сервиса между клиентом и дизайном внутреннего приложения

Question

Я создаю веб-сервис wcf, который будет принимать много непрерывных запросов, веб-сервис должен будет удерживать эти запросы до тех пор, пока внутреннее приложение (которое будет опрашивать веб-сервис каждые пару секунд) не выполнит запрос веб-сервис, чтобы определить, существуют ли какие-либо запросы и получить их, если таковые имеются. Затем внутреннее приложение отправит ответ обратно веб-службе, которая передаст ответ исходному вызывающему.

IE:

Клиент --- 1) Запрос ---> Веб-служба <--- 2) Запрос --- Внутреннее приложение </p>

Клиент <- 4) Ответ --- Веб-служба <--- 3) Ответ --- Внутреннее приложение </p>

Я пытаюсь спроектировать реализацию веб-сервиса и пытался придумать, как реализовать механизм, который будет принимать запрос, удерживать его, пока внутреннее приложение не сделает запрос данных, и веб-сервис не будет ждать за ответ из внутреннего приложения.

Мои основные проблемы:

1) Что, если тысячи запросов поступят до того, как внутреннее приложение сделает запрос, как их следует обрабатывать?

2) Что, если внутреннее приложение умирает и накапливается огромное количество запросов? (Мне нужно будет тайм-аут этих запросов)

3) Как связать первоначальный запрос с клиентом и ответ из внутреннего приложения?

4) Клиент будет ждать, ожидая ответа.

Поможет ли в этой ситуации очередь сообщений WCF? Если бы веб-служба могла управлять Очередью сообщений внутренне, как, например, при поступлении сообщения в веб-службу, это добавило бы сообщение в очередь и аналогичным образом, когда внутреннее приложение делает запрос, веб-служба захватывает сообщение сверху очередь и передает его внутреннему приложению, ждет ответа от внутреннего приложения и передает его обратно клиенту?

Это вообще возможно?

Что, если запрос клиента 2000 поступит одновременно, так как клиент будет синхронно ожидать ответа, будет ли работать описанный выше сценарий? Смогу ли я сопоставить исходный запрос с ответом из внутреннего потока приложений, чтобы предоставить ответ клиенту?

Метод очереди сообщений кажется излишним? Могу ли я просто держать запросы в каком-то статическом словаре?

У вас есть другие предложения?

Answer 1

Во-первых, честно говоря, архитектура типа опроса звучит очень неправильно для обработки запросов в реальном времени. Если вообще возможно перенаправить запросы непосредственно в приложение, которое будет их обрабатывать, это будет бесконечно предпочтительным. Вы открываете себя целому ряду дополнительных проблем, и вы ограничиваете даже время ответа в лучшем случае до «пары секунд», что ужасно.

Но. Предполагая, что вы ничего не можете сделать с архитектурой, постановка в очередь сообщений для извлечения внутренним приложением не является проблемой. Структура очереди в памяти может справиться с этим штрафом (просто ограничьте размер очереди до пары тысяч и верните ошибку, если она заполнится). Вашим настоящим узким местом будет количество открытых запросов в веб-сервисе. Я просто не понимаю, как указанная архитектура сможет обрабатывать тысячи запросов в секунду, если каждый запрос имеет минимальное время открытия "пару секунд". Серверы не предназначены для того, чтобы держать столько запросов открытыми. Те, кто способен обрабатывать тысячи запросов в секунду, делают это, отвечая на каждый запрос в течение нескольких миллисекунд, а затем очищая его. Если каждый запрос открыт в течение нескольких секунд, он будет оштукатуривать ваш сервер - запросы будут помещаться в очередь, и 90% из них будут заканчиваться тайм-аутом, при условии, что ваш сервер не падает при весе.