В принципе ничем, кроме того, что для подписки отписки на коллбэк надо какой то протокол придётся вводить. Вот собственно сий протокол меня и интересует.
Все равно я не понял. Вот я говорю «выполни вот этот долгий http-запрос, когда придет ответ - вот тебе функция, дерни ее» (ну вроде вполне реалистичный же пример и вы, скорее всего, с ним сталкивались и знаете как это реализовать). Что мешает сделать то же самое для «пихни вот это сообщение в очередь, когда придет ответ - вот тебе функция, дерни ее»?
Если говорить о «протоколах» - я бы вообще делал микросервис независимым. Зачем заморачиваться с коллбэками (городя еще и адресацию и борясь с результатами падений инстансов если у вас там MQ), когда можно сделать отдельный микросервис (ну или в том же, не суть), который будет принимать «ответы» и выполнять какие-то действия с ними (то есть по сути ваши коллбэк-функции использовать)?
Мне кажется вы либо не так используете микросервисы, либо не там. А с учетом того что необходимость очередь для вас ад я вообще не понимаю как вы их планировали строить.
В чем проблема обмениваться в обе стороны? У меня есть микросервис M1, слушающий очередь Q1, и микросервис M2 с очередью Q2. М1 кладет сообщение в Q2, M2 его обрабатывает и кладет ответ в M1.
Ну обычно ответ кладут во временные очереди прибытые к конкретному инстансу, иначе, если за очередью стоит балансировщик, то ответ может уйти «не в тот» микросервис который делал запрос, или потребуется городить умный балансировщик.
Deleted ()
Последнее исправление: Deleted
(всего
исправлений: 1)
Ну это как вариант, не суть, принцип с очередями то такой. Но опять же я слабо представляю что должен делать микросервис, которому нужны адресные ответы от других микросервисов. В моем понимании и в том с чем сталкивался микросервисы всегда стараются делать такими, чтоб их можно было без проблем (да хоть в автоматическом режиме) поднимать\опускать, и падение одного инстанса не сказалось бы на бизнес-логике аппликухи. Сюда вот это вот распределение ответов никак не вяжется. Так что для общего развития я бы хотел увидеть какое-то описание такого сервиса.
Мне кажется вы либо не так используете микросервисы, либо не там.
Мне тоже, но оно есть как есть.
Про очереди я понял. Проблема моя в том, что есть rpc но нет очередей. И видна пока только перспектива - делать очереди вручную как отдельные микросервисы. Вот подумал, что думаю не в ту сторону.
Но опять же я слабо представляю что должен делать микросервис, которому нужны адресные ответы от других микросервисов.
Нюанс в том, что Ъ микросвервис должен быть stateless, но хипсторы берут и обмазывают микросервисами http приложения, с авторизацией и прочим.
Получается, с позволения сказать, архитектура вида:
веб_шлюз - куча_микросервисов - единая_база (это отдельный анекдот)
микросервисы как правило «пустые» (там капля бизнеслогики, _синхронные_ вызовы к другим микросевисам и вызовы к базе)
Работает это так: на шлюз приходит запрос, шлюз дёргает микросервис авторизации, ждёт ответа, потом дергает микросервис логики, тот дёргает микросервис авторизации (здесь я уже ржу), получив ответ лезет в базу, возвращает ответ в шлюз
Эта мысль меня посещала, но статическая типизация интерфейсов тут слегка создаёт проблемы, хотя отказываться от неё вроде бы и не хотелось.
Дело в том, что я имею практически тру микросервисы, которые живут как отдельные сервера(местами на разном транспорте) и знают только о тех серверах о которых им сообщили при старте.
Т.е. по идее, если развивать мысль, должен быть свой сервер очереди сообщений к которому можно делать запросы по rpc, в том числе и блокирующие вида wait_event но это пахнет несвежей и неуместной лапшой. Но любая унификация такого подхода ведёт опять же ко всяким двойным диспетчеризациям и прочим прелестям.
Хочется хороший механизм который позволял бы серверу A, сообщить, что другой сервер B предоставляет метод callback() по такому то адресу и серверу A необходимо так же стать клиентом B и вызывать метод callback в ответ на событие.
Но это как то попахивает как минимум авторизацией, если следить за секурностью например. Вот протокол таких взаимоотношений поверх rpc мне в основном и интересен.
Если тебе нужен результат в текущем контексте, то в любом случае придется ждать. На http запросе или на коллбеке.
Если результат не нужен в текущем контексте, то это отдельный сервис, который обрабатывает результат этой длинной операции и коллбек тут еще более вреден.
Ну соединение и так не будет разрываться, иначе ответа мы не дождемся. Как вы уже написали - все зависит от задачи, иногда действительно ответ нужен прямо сейчас и если время ожидания будет большим мне кажется «красивее» повесить на него коллбэк. Хотя я не смогу обосновать это решение и разницы, по сути, никакой не вижу.
Хочется хороший механизм который позволял бы серверу A, сообщить, что другой сервер B предоставляет метод callback() по такому то адресу и серверу A необходимо так же стать клиентом B и вызывать метод callback в ответ на событие.