И снова привет!

Изучение микросервисов продолжается, и тема эта покрыта миллионами вопросов.

Кто имел опыт проектов с использованием МС и таки там была реализация "на каждый сервис своя БД" ? (БЕЗ ИСПОЛЬЗОВАНИЯ ПРОКСИРУЮЩИХ МЕХАНИЗМОВ СОЕДИНЯЮЩИХ БД)

Интересует такой вот момент - когда используем одну БД, то данные в ней согласованы, например сохранение вот таких цепочек:
Цепочка 1Клиент -> Заказ -> Изделия -> Позиции заказа -> Детали позиций заказ -> и т.д. до конца.
Цепочка 2Клиент -> Заказ -> Услуги -> Доставка -> Водители и Транспорт -> и т.д. до конца.
Итого:
1) мы можем одним запросом из базы выбрать всю информацию по клиенту. (легкость сохранности, целостности и получения всей инфы)
2) если мы грохаем клиента, то каскадно удаляется вся информация. (нет "мусора")

Я так понимаю, что должен быть механизм, который:
1) находит несвязанные данные
2) убирает мусор

Но как же на самом деле решается вопрос целостности информации в распределенных БД, которые закреплены за своим микросервисом?

Petro123Imperous,
А где было требование на МС своя бд?
Требования как такого не видел, но читая разные доки с примерами, все как один пишут что реализация была именно такая - на каждый сервис своя БД.
И в этом что-то есть, некоторая независимость.
Не будем сейчас брать в учет микросервисы, которые нужны для балансировки нагрузки, и выполняющие одинаковые функции.

Вот тут например пишут:
авторДецентрализация данных

Еще один из важнейших элементов в парадигме микросервисов.
Каждому микросервису по своей базе данных!

забыл никImperousИ снова привет!

Изучение микросервисов продолжается, и тема эта покрыта миллионами вопросов.

Привет! Похвально, но пока у тебя очень слабое понятие о МС. Самое главное что тебе надо понять, что разбиение на микросервисы должно делаться не просто для того чтобы разбить, а чтбы оно решало бизнес-проблему или давало некие другие преимущества. Если данные сильно зависимы - это должен быть один микросевис, и храниться они должны в одной базе, вот и все.
Есть два варианта, когда такое разбиение все же имеет смысл -
1) Данные не умещаются на одном сервере\базе и нужно их масштабировать\оптимизировать. В этом случае, как и при всех распределенных решениях мы немного теряем в consistency, т.е она не будет гарантированной.
2) Когда допустима задержка времени и моментальная консистентность данных не критична, сойдет и eventual.

В таком случае можно разбить на МС, но общение между ними строго асинхронное через immutable message. То есть, если удалили клиента - формируется сообщение ClientDeleted(id) и пуляется в брокер сообщений или условную кафку. Второй МС слушает эту очередь и реагирует на сообщением зачисткой мусора. Как именно зачистка реализована - зависит от тебя

Спасибо! Именно это я и спрашивал.

Герой дняесли приходится иметь разные бд на микросервисах - то вопрос согласования ложиться на плечи фреймворка

можно согласовывать БД через стрим-потоки вроде https://debezium.io/ , через сообщения RabbitMQ, которые обрабатывают сервисы и так далее (CQRS и тп)

Кстати про очереди типа RabbitMQ.
Например есть 3 сервиса.
В RabbitMQ попадает сообщение, что клиента с таким id больше нет.
2 сервиса-подписчика получают это сообщение и грохают у себя в базах инфу по клиенту.
А вот сервис№3 был на тот момент в дауне, и сразу не отреагировал. Получается при старте сервиса№3 нужно прочитать из очереди все сообщения с того момента как сервис был "положен" и поочередно выполнить соответствующие инструкции.

Так оно работает?

Petro123Imperous,
Слушай, ты журналист для интервью или программист?
Тут программисты в ветке.
Ты плодишь темы без всякого смысла и ЗАДАЧИ.
Прошлую тему про МС чем ты подытожил?
Дай ссылку.
А твой код позже попросим.
1) В Java я новичок.
2) Именно поэтому я тут задаю вопросы, а не бабкам на привозе.
3) Я задаю вопросы которыми в данный момент задался. Изучаю материал, я всегда стараюсь разобраться в интересующей меня теме. Кроме форума я читаю достаточно количество статей, и на русском и на английском, и да, мне не всегда ясно что к чему. Это направление для меня ново. Некоторые слова я вообще впервые вижу. К сожалению могу заметил, что многие статьи в первую очередь ориентированны на тех кто уже знаком с материалом, и новичку сложно понять что происходит. Не так что вот смотрите, есть "1 + 1 = 2", в стиле "Хо-па с 11 цифры после запятой в числе Пи идет последовательность 8979323846", и ты такой "а при чем здесь вообще Пи?".
Не видишь смысла, не хочешь узнавать новое, пожалуйста не открывай темы в которых увидишь автором меня.
4) Какую именно прошлую? В которой дали ссылки на материал? Или в которой развели абстрактный флуд?
5) На свой гитхаб? Но ты там совершенно не увидишь микросервисов.