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

 Помогите разобраться с микросервисной архитектурой.  

На данный момент работают 3 разные программы.  

1-я программа получает данные и записывает одинаковые данные в БД№1 и БД№2.  

2-я программа выполняет свою логику с БД№1.  

3-я программа выполняет свою логику с БД№2.  

  

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

  

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

  

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

Как быть в такой ситуации?   

Имеют ли право на жизнь микросервисы с архитектурой по типу "звезда" (в центре БД, а по кругу микросервисы)?  

  

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

Помогите найти решение этой архитектурной задачи. 

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

  

Именно.  

  

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

  

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

  

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

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

  

  

вот именно. Поэтому каждый микросервис работает со своими данными. И отвечает за них тоже он и никто другой.   

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

  

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

  

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

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

  

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

  

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

 Любой чудак говорящий что ваш бизнес выиграет от микросервисов врет!  

Исходя из этого постулата можно начинать говорить:  

Плюсы "монолита" с базой внутри звезды  

1. Вы переиспользуете бд, что кстати самая сложная штука по любому  

2. Вы балансируете нагрузку без всяких заморочек *  

3. Прокидуете взаимодействие и всяких DEVops  

  

Минусы  

1. вы держите в голове всю структуру БД (это сложно, но как то удавалось?)  

2. вам не нужно идти через http(s) за данными (или это не минус)  

3. вам не нужно настраивать клаймы и прочие https (у вас есть все из коробки) Черт а это точно минус?  

4. У вас один бинарник (и какой вы после этого гуру?)