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

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

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

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

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

По большому счёту все 3 программы выполняют одну большую работу, каждый на своем уровне.
Помогите найти решение этой архитектурной задачи.
  • Вопрос задан
  • 546 просмотров
Решения вопроса 1
sergey-gornostaev
@sergey-gornostaev Куратор тега Java
Седой и строгий
Но немаловажная суть микросервисов в том, что бы минимизировать зависимости, в том числе обеспечить каждый микросервис своей БД.

Именно.

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

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

Может быть вам просто не нужны микросервисы, какую проблему вашего проекта решает микросервисная архитектура? А может вы наоборот зря заморачиваетесь по поводу дублирования, какие проблемы у вас с ним?
Ответ написан
Пригласить эксперта
Ответы на вопрос 3
Robur
@Robur
Знаю больше чем это необходимо
Но немаловажная суть микросервисов в том, что бы минимизировать зависимости, в том числе обеспечить каждый микросервис своей БД. Дублировать данные для каждого микросервиса нет никакого смысла.


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

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

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

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

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

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

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы
Bell Integrator Ростов-на-Дону
от 100 000 до 180 000 ₽
XCritical Software Санкт-Петербург
До 250 000 ₽
от 80 000 ₽