Как поделить базу между микросервисами?

Question

[Crunkor]

Помогите разобраться с микросервисной архитектурой.
На данный момент работают 3 разные программы.
1-я программа получает данные и записывает одинаковые данные в БД№1 и БД№2.
2-я программа выполняет свою логику с БД№1.
3-я программа выполняет свою логику с БД№2.

2-я и 3-я программы иногда общаются между собой, дополняя свои таблицы.

Все 3 программы написаны на разных языках.

Теперь я хочу перевести всё это на Java в микросервисы. В моем видении эти все программы вписались бы в минимум 3 микросервиса. Но немаловажная суть микросервисов в том, что бы минимизировать зависимости, в том числе обеспечить каждый микросервис своей БД. Дублировать данные для каждого микросервиса нет никакого смысла.
Как быть в такой ситуации?
Имеют ли право на жизнь микросервисы с архитектурой по типу "звезда" (в центре БД, а по кругу микросервисы)?

По большому счёту все 3 программы выполняют одну большую работу, каждый на своем уровне.
Помогите найти решение этой архитектурной задачи.

Answer 1

[Сергей Горностаев]

Но немаловажная суть микросервисов в том, что бы минимизировать зависимости, в том числе обеспечить каждый микросервис своей БД.

Именно.

Дублировать данные для каждого микросервиса нет никакого смысла.

В микросервисной архитектуре в дублировании как раз есть смысл.

Может быть вам просто не нужны микросервисы, какую проблему вашего проекта решает микросервисная архитектура? А может вы наоборот зря заморачиваетесь по поводу дублирования, какие проблемы у вас с ним?

Answer 2

[Robur]

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

вот именно. Поэтому каждый микросервис работает со своими данными. И отвечает за них тоже он и никто другой.
Если у вас данные дублируются - то это уже большой повод задуматься.

Если с какими-то данными, за который отвечает микросервис А нужно что-то сделать в микросервисе Б, то надо не дублировать их в Б, а поменять А чтобы он предоставлял апи для работы с этими данными, и вызывать это апи из Б. Дальше А уже сделает то что нужно.

Конечно для правильного разделения надо будет пересмотреть архитектуру, структуру данных, логику работы и прочее. Но вы вроде этим как раз и хотите заняться а не просто "переписать на java"

Answer 3

[SirotaKazansky]

Не очень понимаю зачем нужно столько сетевых транзакций (записали в одну БД, записали во вторую БД, обменялись данными и записали в свои БД), и зачем слой доступа к данным делать отдельным сервисом, как здесь предлагали - чем это поможет?

Я думаю стоит руководствоваться бизнесовой логикой при разделении на сервисы. И стоит поразмыслить какую проблему мы устраняем и какую создаём, когда выделяем сервис в отдельный, опять исходя из бизнеса - могут ли эти сервисы жить друг без друга, может у вас одна транзакция проходит через 2 и 3 программы последовательно, и не имеет смысла, если что-то упало - нужно откатывать назад тогда состояния. Подумать что будет если данные между БД рассинхронизируются, важно ли им быть синхронными. Какие объемы данных, какие требования по скорости и т.д. и т.п.

Считаю что на уровне "есть программы, есть база, они что-то делают" - невозможно определить нужность и правильность разделения.

Answer 4

[Владимир Коротенко]

Любой чудак говорящий что ваш бизнес выиграет от микросервисов врет!
Исходя из этого постулата можно начинать говорить:
Плюсы "монолита" с базой внутри звезды
1. Вы переиспользуете бд, что кстати самая сложная штука по любому
2. Вы балансируете нагрузку без всяких заморочек *
3. Прокидуете взаимодействие и всяких DEVops

Минусы
1. вы держите в голове всю структуру БД (это сложно, но как то удавалось?)
2. вам не нужно идти через http(s) за данными (или это не минус)
3. вам не нужно настраивать клаймы и прочие https (у вас есть все из коробки) Черт а это точно минус?
4. У вас один бинарник (и какой вы после этого гуру?)