Имеем следующую инфраструктуру: развернуто несколько инстанций сервера мобильного приложения, они обращаются к другому внутреннему сервису по протоколу SOAP, у внутреннего сервиса тоже несколько инстанций, каждая его инстанция может выполнять одновременно определенное количество запросов, для распределения нагрузки между сервисами сейчас используется nginx с модулями ngx_http_upstream_module и ngx_http_limit_req_module.
От менеджера проекта поступила задача, завернуть HTTP запросы в сообщения для брокера очередей (любой менеджер очередей), и использовать эти очереди для балансировки нагрузки на внутренний сервис, т.к. в пиковое время его производительности не достаточно для нормальной работы приложения.
Никакой информации по это вопросу не нашел, хотелось бы услышать мнение других, возможно у кого-то был подобный опыт, и вообще в целом о целесообразности подобного решения.
Чтобы оценить целесообразность надо понимать цель. Если цель "не потерять ни одного запроса", то целесообразно. Вот только я сомневаюсь, что все эти запросы нужно обрабатывать. Потому что они будут терять актуальность быстрее чем обрабатываться. Тут может помочь какой-то интеллектуальный троттлинг.
Есть хороший доклад от СКБ-Контур примерно на эту тему
preblud, я думаю проблема не в этом, а в том что менеджер проекта не ставит вам задачу, а говорит "реализуй моё решение задачи, а в чем задача не скажу". Нужно добиться от него четкой постановки задачи, желательно в цифрах, сколько запросов в секунду, какие сервисы критичны, какие не критичны и могут отказывать, после какого времени пользователю ответ не важен и т.д.
Выполнять задачи в очереди можно если задачи могут выполняться отложенно. При обработке в очереди нет гарантии выполнения в заданный срок времени и механизмы взаимодействия при этом усложняются.
Для управления нагрузкой в пиковое время необходимо горизонтально масштабировать экземпляры приложения при повышении нагрузки сверх заданного лимита. По ходу, может понадобиться масштабирование СУБД.
