Я пытаюсь оптимизировать микросервисную архитектуру, которая в настоящее время использует HTTP/REST для внутренней связи между узлами.
Одним из вариантов является реализация возможности обратного давления в сервисах, например, путем интеграции чего-то вроде Quasar в стек. Это, без сомнения, улучшит ситуацию. Но я вижу пару проблем. Во-первых, асинхронные клиентские потоки являются временными (в памяти), и при сбое клиента (сбое) эти потоки повторных попыток будут потеряны. Во-вторых, теоретически, если целевой сервер не работает в течение некоторого времени, клиент может в конечном итоге достичь OOM, пытаясь повторить попытку, потому что потоки в конечном итоге ограничены, даже Quasar Fibers.
Я знаю, что это немного параноидально, но мне интересно, будет ли альтернатива на основе очереди более выгодной в очень больших масштабах.
Он по-прежнему будет работать асинхронно, как Quasar/fibers, за исключением того, что: а) очередь управляется централизованно и вне клиентской JVM, и б) очередь может быть устойчивой, так что в случае отказа клиента и/или целевых серверов сообщения в полете отсутствуют. потеряны.
Недостатком очереди, конечно, является то, что количество прыжков больше, и это замедляет работу системы. Но я думаю, что, вероятно, есть благоприятная точка, где достигается пик окупаемости инвестиций Quasar, а централизованная и надежная очередь становится более важной для масштабирования и высокой доступности.
Мой вопрос:
Этот компромисс обсуждался? Есть ли документы по использованию централизованной внешней очереди/маршрутизатора для внутрисервисной связи.
TL;DR; Я только что понял, что, вероятно, мог бы сформулировать этот вопрос так:
«Когда уместно использовать внутрисервисную связь на основе шины сообщений, а не прямой HTTP в архитектуре микросервиса».
