Зачем в микросервисах используют HTTP/REST, если есть очереди, и почему не все запросы кладут в очередь
Что проверяют
Понимаете ли вы, что выбор диктуется сценарием, а не модой. Ответ «очереди надёжнее, значит везде очереди» показывает нехватку опыта эксплуатации.
Как отвечать
Главное различие в том, нужен ли ответ прямо сейчас. HTTP это вопрос и ответ в одном обращении: клиент ждёт результат и может показать его пользователю. Очередь это передача задачи дальше: отправитель получает подтверждение приёма, а результат появится позже.
Почему HTTP остаётся:
- синхронные сценарии: проверка прав, получение профиля, поиск, расчёт цены. Пользователь ждёт ответ на экране, и превращать это в очередь бессмысленно;
- простота отладки и эксплуатации: коды ответов, трассировка, знакомые инструменты, понятная обратная связь при ошибке;
- обратное давление естественно: сервис не справляется, он отвечает ошибкой или задержкой, и клиент это видит. В очереди перегрузка превращается в растущее отставание, которое надо отдельно наблюдать;
- меньше движущихся частей: брокер это ещё одна система, которую надо поддерживать, мониторить и обновлять.
Почему очередь всё-таки нужна: длинные операции, всплески нагрузки, доставка события нескольким подписчикам, устойчивость к недоступности получателя, работа, которую можно выполнить позже.
Практический вывод: чтение и синхронные проверки по HTTP, а тяжёлые побочные эффекты (письма, отчёты, индексация, начисления) через очередь. Часто это сочетается в одном сценарии: сервис принимает запрос по HTTP, кладёт задачу в очередь и сразу возвращает статус.
Где спотыкаются
Переводят всё на события и получают систему, где невозможно ответить пользователю «готово».
Считают очередь бесплатной надёжностью, забывая про дубли, порядок и разбор недоставленных сообщений.
Делают синхронный вызов внутри обработчика очереди без таймаута и получают зависшего потребителя.