LINUX.ORG.RU

Коммуникации между микросервисами

 , ,


1

1

Добрый день! Хочется начать новый домашний, но довольно таки масштабный проект. Приглянулась идея микросервисов - модно, все в контейнерах, удобно, но есть вопрос о best practices микросервисного взаимодействия. Делать каждый запрос поверх http - да ну... Redis неудобно. Есть ли уже готовые имплементации «очередей с ожиданием ответа», RPC основанного на очередях? Делается все на java.



Последнее исправление: matroskin (всего исправлений: 1)

RabbitMQ? Есть и синхронный и асинхронный пример.

anonymous
()

Нормальные пацаны использовали remote EJBs еще до того, как хипстеры «придумали» микросервисы.

Deleted
()
Ответ на: комментарий от znenyegvkby

Предположим, что M1 делает запрос на M2, M2 уже загружен по уши запросами. Т.к. у нас http мы можем настроить балансировку нагрузки на nginx, но зачем, если мы можем использовать amqp + десяток сервисов m2, «балансировка» из коробки.

matroskin
() автор топика
Ответ на: комментарий от matroskin

HTTP + JSON удобен отладкой (запрос можно хоть curl-ом зафигачить) и простотой интеграции разнородных инфраструктур. Поддержка HTTP есть наверное даже в COBOL-е, а вот биндинги к этому вашему amqp — не факт.

А так да, JMS и всякие MQ давным давно придумали. Можно даже делать такие крутые штуки, как транзакции одновременно к БД и к MQ, т.е. мы либо выполняем действие в БД и вытаскиваем сообщение из MQ, либо случается проблема и откатывается транзакция и в БД и сообщение возвращается назад.

Legioner ★★★★★
()
Ответ на: комментарий от anonymous

Да, плюсую за Akka. И вообще за реактивное программирование. У Akka, как я помню были remote actors неплохи.

Deleted
()

Хочется начать новый домашний, но довольно таки масштабный проект.

Ты его главное начни и раскрути, а там уже будут понимание что и как переделать, первый вариант все равно в утиль.

Если все таки хочется заморочиться есть message queues и remote ejb. При сильной любви к вебу - soap или json rpc.

ya-betmen ★★★★★
()
Последнее исправление: ya-betmen (всего исправлений: 1)
Ответ на: комментарий от ya-betmen

При сильной любви к вебу - soap

И при сильной любви к километровым xml-ям. Это еще же парсить/генерить надо. У меня уже на слова SOAP, XML, XSD и JAXB сильная аллергия.

Deleted
()
Ответ на: комментарий от anonymous

нормальный пацаны сделали erlang ещё до появления йавы.

Нормальные пацаны нужные библиотеки запелить не забыли, например для базы данных postgresql, mariadb, etc?

anonymous
()
Ответ на: комментарий от Deleted

Это еще же парсить/генерить надо.

Будто ты каждый запрос руками пишешь.

Внезапно парсить/генерить сообщения нужно с любым текстовым протоколом.

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

ya-betmen ★★★★★
()

Изучайте

- Apache ActiveMQ

- Apache Camel

и переходите к Apache Karaf и ServiceMix.

Bioreactor ★★★★★
()
Ответ на: комментарий от matroskin

Это все на любителя. Мне нравится удобство rest+json, а если уж и говорить о ситуации с высокой нагрузкой, то что ваш «балансировщик из каробки» будет бюджетным вариантом, что дефолтный DNS-rr. А для внедрения нормального алгоритма балансировки придется попотеть что здесь, что там.

znenyegvkby
()
Ответ на: комментарий от sT331h0rs3

но это уже старьё, а не молодёжно :)

Молодежно это я про REST для коммуникации. А JSON почему устарел? Откуда дровишки-то?

znenyegvkby
()
Ответ на: комментарий от znenyegvkby

Ему на смену приходит новомодный YAML. Он ещё мало где используется, но вот именно в плане новизны он выигрывает у JSON.

sT331h0rs3 ★★★★★
()
Ответ на: комментарий от sT331h0rs3

Ему на смену приходит новомодный YAML.

Новомодный? Я наоборот когда в вебе работал в симфони его юзал для конфиг. А теперь уже два года как забыл про него.

znenyegvkby
()

модно

очуметь техническая аргументация. единственный best practice - забыть про это слово в программировании.

dzidzitop ★★
()
Ответ на: комментарий от dzidzitop

Так внутренний проект же, самое место посмотреть в сторону изученного и используемого повсеместно, расширить границы сознания.

matroskin
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.