Мне очень нравится концепция запроса-ответа как слабо связанного канала связи, который может заменить традиционную связь REST между микросервисами.Мое единственное беспокойство основано на факте, указанном в документах https://nats -io.github.io / docs / developer / concepts / reqreply.html , что при наличии нескольких подписчиков на одну и ту же тему все вызываются и толькоодин ответ (самый быстрый) используется абонентом.Это поведение запрограммировано без возможности изменения?Разве не существует какой-либо опции, что NATS выберет только одного подписчика (с использованием некоторого циклического подхода) и отправит запрос этому?
Давайте рассмотрим этот пример:
У нас есть микросервис, который обслуживает персональные данные для других микросервисов ... базовые операции CRUD с использованием REST.Теперь мы должны иметь возможность заменить его, используя набор подписчиков NATS для каждой операции CRUD, например, «person.read», «person.list», «person.create», «person.delete».Мы можем сделать это и создать запрос NATS от других микросервисов для «person.read» с определенным идентификатором.Теперь, когда есть один подписчик, он работает нормально, и подписчик загрузит человека из базы данных и ответит вызывающему абоненту через NATS.Но что, если мы хотим масштабировать персональные услуги и добавить подписчиков, чтобы справиться с большей нагрузкой?Теперь, используя этот подход «запрос-ответ», все подписчики называются «person.read» ... в этом случае это просто напрасная трата ресурсов, поскольку используется только один ответ ... и это также не масштаб, поскольку все подписчики должны были это сделать.Работа.Но давайте представим, что мы называем "person.create" новыми данными JSON от человека.Все абоненты теперь вызываются снова, например, 4 подписчика создают одну и ту же запись о человеке 4 раза в базе данных.И это не совсем то, что мы хотим.
Что-то вроде этого полностью выходит за рамки и цели NATS?Или как правильно добиться этого с помощью NATS?
РЕДАКТИРОВАТЬ 1: Хорошо, только что обнаружил, что я могу использовать функцию групп очередей https://nats -io.github.io / docs / developer/concepts/queue.html даже для связи запрос-ответ.Поэтому, когда у меня несколько подписчиков в одной группе очередей, по запросу вызывается только один si.Большой!Это то, что я хочу.Итак, последний вопрос остается ... эта концепция в целом хорошо?