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

1

1

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

Ссылка

←	python 2.7 изучения тред

Привет, я нуб!

→

Показаны ответы на комментарий. Показать все комментарии.

Ответ на: комментарий от znenyegvkby 18.07.16 11:13:02 UTC

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

matroskin ★
(18.07.16 11:48:10 UTC) автор топика

Ответ на: комментарий от matroskin 18.07.16 11:48:10 UTC

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

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

~~Legioner~~ ★★★★★
(18.07.16 12:06:43 UTC)

Ссылка

Ответ на: комментарий от matroskin 18.07.16 11:48:10 UTC

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

znenyegvkby ★
(19.07.16 06:24:09 UTC)