Использование RabbitMQ для связи в стиле RPC: шаблон convertSendAndReceive и стиль push / подписки

Question

Я реализую коммуникацию в стиле RPC с использованием RabbitMQ с идеей создания асинхронной конвейерной архитектуры.Я работаю с Java Spring и AMQP.

Я выполню цепочку связи в стиле RPC - связь с одним сервером вызовет еще один, а другой вызовет другой, пока, наконец, не достигнет концацепочки и сервер, запускающий цепочку, получающий окончательный ответ.Я нашел два метода, которые, кажется, удовлетворяют моим потребностям:

1. asyncRabbitTemplate convertSendAndReceive(...): нажмите, используя этот метод, как только потребитель получит, вызовите другой convertSendAndReceive(...) и такна ... цепочке, пока окончательный результат не окажется на сервере, который инициировал весь процесс.

2. использовать шаблон push / подписки, где один производитель будет нажимать, используя convertAndSend(...), aпотребитель будет слушать через @RabbitListen и нажимать на другого, который слушает и т. д .;в этой настройке сервер с начальным вызовом convertAndSend(...) получит окончательный ответ.

Я не уверен, в чем разница между этими подходами?Когда идти на один или другой?Есть ли компромисс производительности?Один требует больше усилий по программированию, чем другой?

Answer 1

Это должен был быть комментарий к ответу @ theMayer. Тем не менее, я хотел бы остановиться на деталях RPC с изображением. @ theMayer не стесняйтесь встраивать это изображение, если хотите, тогда я удалил бы этот ответ.

Вызов RPC обычно выполняется следующим образом:

Answer 2

Как я понимаю, вы строите каскад событий, который должен закончиться в начале. Шаблон RPC предназначен для прямых вызовов между двумя сторонами, которые знают друг друга.

Таким образом, вы определенно можете перейти к темам, если вы можете определить, как ваши данные преобразуются после каждой станции (например, metal_bar -> squeezed_metal_bar -> curved_metal_bar -> spoon), это позволит независимо масштабировать каждую станцию ​​и даже добавлять сервисы, которые отслеживают / реагировать на любой из этапов, ничего не меняя, но остерегаться масштабирования исходного абонента - вам может понадобиться решение этой проблемы

Answer 3

Я думаю, здесь есть концептуальная проблема.У меня нет удобного инструмента диаграммы последовательности, но в RPC,

1. У нас есть потребитель C и поставщик P
2. C отправляет сообщение на P , чтобы вызвать службу, предоставляемую P
3. P , непосредственно отвечает на C с результатами, запрашиваемыми в C сообщении с запросом

Все, что не является НЕ RPC.Другие термины, которые я использовал для описания этого, это «запрос / ответ» и «клиент / сервер».Это шаблон, используемый практически всеми веб-сервисами, поэтому он повсеместен в архитектуре приложения.

Практика, которую вы здесь описываете, известна как цепочка событий .Это кажется достаточно простым в концепции, но то, что вы на самом деле имеете, - это серия независимых действий, которые все организовывают сами.Это то, как работает реальный мир, и ключевая особенность реального мира в том, что он недетерминирован .Это означает, что при одинаковой последовательности действий результирующий вывод не гарантированно будет одинаковым.

Большинство компьютерных программ полагаются на детерминированное поведение, когда одни и те же входные данные всегда приводят кточно такие же выходы.