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

Question

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

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

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

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

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

Мой вопрос:

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

TL; DR; я просто понял, что я мог бы, вероятно, фраза этот вопрос:

«Когда это целесообразно использовать Message Bus на основе intraservice коммуникации в отличие от прямого HTTP в архитектуре microservice »

Answer 1

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

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

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

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

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