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

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

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

Делать каждый запрос поверх http - да ну...

И чем тебе REST+JSONformat не угодил? Стильно, можно, молодежно.

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

Scala + Akka + Slick отлично масштабируемая связка.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Изучайте

- Apache ActiveMQ

- Apache Camel

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

Спасибо за наводку, тоже взгляну на Akka.

Как я понял, с «верблюдом» её подружить можно -

http://www.slideshare.net/krasserm/system-integration-with-akka-and-apache-camel

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

Не то чтобы я против жсонов, но это уже старьё, а не молодёжно :)

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

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

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

2016
новомодный YAML

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

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

модно

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

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