Шина сообщений и Quasar/HTTP для внутренних вызовов микросервиса

Question

Я пытаюсь оптимизировать микросервисную архитектуру, которая в настоящее время использует HTTP/REST для внутренней связи между узлами.

Одним из вариантов является реализация возможности обратного давления в сервисах (например) путем интеграции чего-то вроде Quasar в стек. Это, несомненно, улучшит ситуацию. Но я вижу пару проблем. Во-первых, асинхронные клиентские потоки являются временными (в памяти), и при сбое клиента (сбой) эти потоки повторных попыток будут потеряны. Во-вторых, теоретически, если целевой сервер не работает в течение некоторого времени, клиент может в конечном итоге достичь OOM, пытаясь повторить попытку, потому что потоки в конечном итоге ограничены, даже Quasar Fibers.

Я знаю, что это немного параноидально, но мне интересно, будет ли альтернатива на основе очередей более выгодной в очень большом масштабе.

Он по-прежнему будет работать асинхронно, как Quasar/fiber, за исключением того, что: а) очередь управляется централизованно и не поддерживается клиентской JVM, и б) очередь может быть надежной, так что в случае сбоя клиентский и / или целевой серверы отключаются, а сообщения в полете отсутствуют. потеряны

Недостатком очереди, конечно, является то, что есть больше прыжков, и это замедляет работу системы. Но я думаю, что, вероятно, есть приятное место, где пики рентабельности инвестиций Quasar и централизованная и долговременная очередь становятся более важными для масштабирования и высокой доступности.

Мой вопрос:

Обсуждается ли этот компромисс? Есть ли какие-либо документы об использовании централизованного подхода с использованием внешней очереди / маршрутизатора для внутрисервисного взаимодействия.

TL; DR; Я просто понял, что мог бы сформулировать этот вопрос следующим образом:

"Когда целесообразно использовать внутрисервисную связь на основе шины сообщений, а не прямой HTTP в микросервисной архитектуре".

Answer 1

Я видел три общих шаблона проектирования протоколов с архитектурами микросервисов при работе в масштабе:

1. Архитектура шины сообщений с использованием центрального посредника, такого как ActiveMQ или Apache Qpid.
2. "Устойчивый" HTTP, где некоторая дополнительная логика построена на HTTP, чтобы сделать его более устойчивым. Типичными подходами здесь являются Hystrix (Java) или SmartStack/Baker St (умный прокси).
3. Двухточечная асинхронная передача сообщений с использованием чего-то вроде NSQ, ZMQ или Qpid Proton.

Безусловно, наиболее распространенным шаблоном проектирования является № 2, с небольшим количеством #1, смешанным, когда очередь желательна.

Теоретически, #3 предлагает лучшее из обоих миров (устойчивость, масштаб и производительность), но все технологии несколько незрелые. Оказывается, что с #2 вы можете продвинуться очень далеко (например, Netflix везде использует Hystrix).

Чтобы ответить на ваш вопрос напрямую, я бы сказал, что № 1 очень редко используется в качестве эксклюзивного шаблона проектирования, поскольку он создает единственное узкое место для всей вашей системы. № 1 является общим для подмножества системы. Для большинства людей я бы порекомендовал № 2 сегодня.