Паттерн где для одного сервиса - 1 база, распространён и имеет преимущество в виде возможности разнести нагрузку на базу, всегда одного ответственного за базу, но и имеет минусы:
- Необходимость управлять группой транзакций, если она затрагивает несколько сервисов
- Зависимости между микросервисами, которые сложно отследить.
- Не удобное использование данных для аналитики, так как они разнесены.

Для уменьшения связанности и управления транзакциями лучше всего использовать паттерн saga, где есть управляющий сервис, который оркестрирует микросервисы. Это может быть даже само API, но лучше делать отдельный сервис под конкретные доменные области, чтобы например управление заказами не замешивались с статьями для сайта.

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

Для обмена также рекомендую Kafka или RMQ (сам всегда использую RMQ). Главное увлекаясь микросервисами не сделать nano сервисы) Для этого советую почитать про DDD.

У меня вопрос, но не по Несту, а больше по микросервисам самим.

Паттерн говорить дб для каждого сервиса. Окей.

Есть вот сервис каталога товаров.
Есть сервис выполненных заказов.
Есть естественно сервис юзеров.


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

Окей, можно использовать Реббит или Кафку и писать в базу заказов уникальных юзеров которые сделали заказ и уникалные товары которые были заказаны?

В принципе МС-ы это хорошо однозначно, но нужно подумать сотню раз нужно ли вам это, ибо потери по скорости работы есть, плюс дополнительная нагрузка на саму систему а целом из-за того что есть дополнительные запросы в несколько сервисов, что в монолите можно было сделать одни запросом в базу.

Если же говорить про логику связи между мс-ами, обычно делают центральный gateway который за это отвечает и получается что МС-ы знать не знают что есть ещё кто-то.

В принципе МС-ы это хорошо однозначно, но нужно подумать сотню раз нужно ли вам это, ибо потери по скорости работы есть, плюс дополнительная нагрузка на саму систему а целом из-за того что есть дополнительные запросы в несколько сервисов, что в монолите можно было сделать одни запросом в базу.

Если же говорить про логику связи между мс-ами, обычно делают центральный gateway который за это отвечает и получается что МС-ы знать не знают что есть ещё кто-то.

@AlariCode привет, спасибо за отличную либу по работе с кроликом, получилось очень даже неплохо.

А что значит что мс не знают что есть ещё кто-то?

Ок, что тут гейтвей тогда? Кто-то кто знает про всех?

Ок, что тут гейтвей тогда? Кто-то кто знает про всех?

А зачем?

Прямые взаимодействия в рамках транзакции через прямые обращение, сайд эффекты через шину