Как реализуется механизм callback в микросервисной архитектуре

А чем в данном случае взаимодействие микросервисов отличается от, скажем, вызова коллбэка при выполнения HTTP-запроса?

В принципе ничем, кроме того, что для подписки отписки на коллбэк надо какой то протокол придётся вводить. Вот собственно сий протокол меня и интересует.

MQ, как вариант.

архитектурный приём?

Жырный мессадж брокер. Типа, apache mq.

Ну и, добро пожаловать в АД.

http://camel.apache.org/asynchronous-processing.html

Все равно я не понял. Вот я говорю «выполни вот этот долгий http-запрос, когда придет ответ - вот тебе функция, дерни ее» (ну вроде вполне реалистичный же пример и вы, скорее всего, с ним сталкивались и знаете как это реализовать). Что мешает сделать то же самое для «пихни вот это сообщение в очередь, когда придет ответ - вот тебе функция, дерни ее»?

Если говорить о «протоколах» - я бы вообще делал микросервис независимым. Зачем заморачиваться с коллбэками (городя еще и адресацию и борясь с результатами падений инстансов если у вас там MQ), когда можно сделать отдельный микросервис (ну или в том же, не суть), который будет принимать «ответы» и выполнять какие-то действия с ними (то есть по сути ваши коллбэк-функции использовать)?

Про ад это я уже вкурил. *mq это печаль конечно.

Это хорошо, до тех пор пока ты не захочешь обмениваться сообщениями в обе стороны. Хотя может я ещё не осознал о чём ты.

Мне кажется вы либо не так используете микросервисы, либо не там. А с учетом того что необходимость очередь для вас ад я вообще не понимаю как вы их планировали строить.

В чем проблема обмениваться в обе стороны? У меня есть микросервис M1, слушающий очередь Q1, и микросервис M2 с очередью Q2. М1 кладет сообщение в Q2, M2 его обрабатывает и кладет ответ в M1.

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

Ну это как вариант, не суть, принцип с очередями то такой. Но опять же я слабо представляю что должен делать микросервис, которому нужны адресные ответы от других микросервисов. В моем понимании и в том с чем сталкивался микросервисы всегда стараются делать такими, чтоб их можно было без проблем (да хоть в автоматическом режиме) поднимать\опускать, и падение одного инстанса не сказалось бы на бизнес-логике аппликухи. Сюда вот это вот распределение ответов никак не вяжется. Так что для общего развития я бы хотел увидеть какое-то описание такого сервиса.

Мне кажется вы либо не так используете микросервисы, либо не там.

Мне тоже, но оно есть как есть.

Про очереди я понял. Проблема моя в том, что есть rpc но нет очередей. И видна пока только перспектива - делать очереди вручную как отдельные микросервисы. Вот подумал, что думаю не в ту сторону.

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

Нюанс в том, что Ъ микросвервис должен быть stateless, но хипсторы берут и обмазывают микросервисами http приложения, с авторизацией и прочим.

Получается, с позволения сказать, архитектура вида:

веб_шлюз - куча_микросервисов - единая_база (это отдельный анекдот)

микросервисы как правило «пустые» (там капля бизнеслогики, _синхронные_ вызовы к другим микросевисам и вызовы к базе)

Работает это так: на шлюз приходит запрос, шлюз дёргает микросервис авторизации, ждёт ответа, потом дергает микросервис логики, тот дёргает микросервис авторизации (здесь я уже ржу), получив ответ лезет в базу, возвращает ответ в шлюз

Только не спрашивайте меня, зачем так делают 8)

Если там уже есть rpc, и там идентификаторы процедур, то просто передавай этот идентификатор, мол, «ответ слать в эту процедуру».

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

Дело в том, что я имею практически тру микросервисы, которые живут как отдельные сервера(местами на разном транспорте) и знают только о тех серверах о которых им сообщили при старте.

Т.е. по идее, если развивать мысль, должен быть свой сервер очереди сообщений к которому можно делать запросы по rpc, в том числе и блокирующие вида wait_event но это пахнет несвежей и неуместной лапшой. Но любая унификация такого подхода ведёт опять же ко всяким двойным диспетчеризациям и прочим прелестям.

Хочется хороший механизм который позволял бы серверу A, сообщить, что другой сервер B предоставляет метод callback() по такому то адресу и серверу A необходимо так же стать клиентом B и вызывать метод callback в ответ на событие.

Но это как то попахивает как минимум авторизацией, если следить за секурностью например. Вот протокол таких взаимоотношений поверх rpc мне в основном и интересен.

статическая типизация интерфейсов тут слегка создаёт проблемы,

это-то тут при чём? тыж всё равно возможность и формат ответа закладываешь при разработке.

сообщить, что другой сервер B предоставляет метод callback()

Адрес куда отвечать, обычно передаётся в запросе.

В чем проблема дождаться ответа сервера не разрывая http соединение?

Ветку не читал :)
А если микросервис занимается какой-нибудь обработкой.
Которая занимает 2ч-10-1день-10дней…
И… ждать?

Если тебе нужен результат в текущем контексте, то в любом случае придется ждать. На http запросе или на коллбеке.

Если результат не нужен в текущем контексте, то это отдельный сервис, который обрабатывает результат этой длинной операции и коллбек тут еще более вреден.

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

Есть протокол amqp который существует как раз для этого.

А про хттп запрос ответ это веб макака пишет. Не обращай внимания.

Хочется хороший механизм который позволял бы серверу A, сообщить, что другой сервер B предоставляет метод callback() по такому то адресу и серверу A необходимо так же стать клиентом B и вызывать метод callback в ответ на событие.

Это какой-то pub/sub