Могут ли микросервисы дублировать данные в своих БД?
Вопрос, который лучше постараюсь сразу обьяснить на примере.
Есть самописная erp/crm система (кодовая база которой в ужасном состоянии, который боишься трогать и всё это на устаревшем стеке) далее буду называть монолит.
У монолита есть сотрудники.
У сотрудников есть: должности, офисы, имена.
Понадобилось сделать небольшой фановый магазин для сотрудников с основными функциями:
- дать возможность задавать правила начисления бонусов для сотрудников (по ролям, должностям с определенной переодичностью)
- дать возможность покупать товары за начисленные бонусы (доступность товара для сотрудника - ограничивается его наличием в офисе)
Собственно в чем сложность - не хочется писать этот магазин внутри монолита, а сделать его отдельно.
Изначально была очень простая идея: пишем отдельным приложением магазин, синхроним переодически по апи из erp/crm сотрудников, офисы, должности (данные изменяются редко) - сохраняем в базу магазина. Всю логику начисления бонусов, управления товарами, покупки пишем в магазе - вроде все счастливы.
Но вчера мы задумались что на самом деле в такие отдельные приложения можно вынести еще ряд функционала из нашего монолита приведя его в порядок. Например : учёт рабочего времени. Он нафиг нафиг не надо монолиту, кроме как для месячного отчета, но содержит в себе кучу логики - праздники в различных офисах, отгулы, больничные и т.д.
И вроде можно сделать все опять очень просто - засинкать из монолита нужную для учёта рабочего времени инфу в еще одну базу и вроде опять все довольны.
Все это начинает смахивать на микросервисы.
Вчера обсудили это с чуваками из другого отдела, которые типо варят микросервисы. Они заговнили это всё, сказав что дублировать инфу синкая её это рак и что нужно тянуть данные по апишке из монолита как-будто из собственной базы.
Тут же возник вопрос: оокей, если для создания правила начисления бонуса нужна инфа о должности и офисе сотрудника - как я такое правило сохраню в магазине? Ответом было: значит правила должны лежать в монолите.
Если придерживаться этой логике, то тут я вообще ничего не понял:
- правила я не смогу держать в магазине, потому что мне нужны офисы сотрудников - уезжает в монолит
- товары я тоже смогу держать в магазине, потому что мне нужны офисы - тоже уезжает в монолит
- для каталога нужны товары, а они в монолите - тоже уезжает в монолит? :D
Может кто че подсказать как такие штуки лучше организовывать или скинуть чтива по вопросу хранения данных, если одна и таже инфа нужна в несколько приложениях?
Обсудил в чате телеграмма. Пришли к выводу - в базе сервиса нужно хранить только айдишки на сущности других сервисов, а сами сущности тянуть из сервисов. Посоветовали книгу - читаю shop.oreilly.com/product/0636920033158.do
Это неверный подход. Верный подход: сервис отправляет в шину событие что его данные изменились, все сервисы, которому нужен кусок таких данных из очереди берут их и сохраняют у себя. Никто 2ой раз не опрашивает сервис.
Каждой сущности - свой микросервис. Один для пользователей - к нему все обращаются, пользователи и непосредственно связанные с ними данные хранятся там; другой для товаров и т.д.
Нет. Каждому контексту свой микросервис. Это 1 иногда 2 агрегата, а не сущности.
связанные с ними данные хранятся там
Нет. сервис пользователей это лишь первоисточник данных. Все данные о пользователях, которые нужны другим микросервисами хранятся в БД тех микросервисов.
Это называется не микросервисы, а интеграция. Обычное дело в мире корпоративных систем. Главное чтобы кой-какое api было, а дублировать ли инфу в дополнительные подсистемы зависит от требований к быстродействию системы и к актуальности данных.
интеграция - это взаимодействие 2х интерфейсов. Она есть и между 2я микросервисами и между монолитом и сервисами. Дублировать ли инфу или нет зависит не от требований, а от выбранной архитектуры. Если люди решили что это мса, то дублирование инфы это часть архитектуры мса. Если не нравится факт дублирования или вам жалко пару гигов на винте - выбирайте другие подходы, например soa или живите в монолите, страдайте из-за других проблем
Они заговнили это всё, сказав что дублировать инфу синкая её это рак и что нужно тянуть данные по апишке из монолита как-будто из собственной базы.
Они некомпетентны, не читали книг, не смотрели видео и делают типичный русский айти-велосипед в виде SOA или распределённый монолит, а не микро сервисы у себя. Т.е. даже не знают чем один подход отличается от другого. Это в SOA сервисы друг друга повторно используют (ещё и модели общие в либах загоняя) делая запросы друг другу в 1ой системе, в МСА сервисы шарят данные, а не запросы, плюс они полностью автономны, они всегда имеют все нужные им данные (дублируют в бд нужную им часть), они никогда внутри одной системы не обращаются синхронно к другим сервисам этой системы (исключения - браузер-api-gateway, некоторые общие словари с адресами, облачные хранилища с большими файлами).
Средний
Средний
Простой
Простой
Простой
