микросервиса на несколько?
Микросервисы же не должны знать о структуре данных других микросервисов. К тому же эта структура может меняться в будущем и миграция может оказаться привязана к промежуточной точке в каком-то микросервисе..
задачи получается две: а) накатить как-то изменения на текущий прод. б) развернуть все с нуля где-то еще.
1) Миграция через внешнее апи? Оно тоже может поменяться и может не давать доступа к каким-то служебным данным.
2) Затягивание данных из сруктуры распиливаемого микросенрвиса новым? Опять же зависимость от структуры (сильное зацепление) и конкретной временной точки.
3) Ручная миграция и схлопывание исходного набора миграций в точке отпочкования нового микросервиса? Но - ручное вмешательство на проде...
Или есть какой-то тру-вей
Как хранить данные сугубо личное дело каждого микросервиса...
Резать на микросервисы исходя из анализа предметной области. При должном анализе получатся микросервисы в которых данные будут развязаны друг от друга. Универсального пути нет, но разбивать на микросевисы следует в разразе ограниченных контекстов, а не как хочется. Если хорошего понимания предметной области и ее ограниченных контекстов нету, микросервисы сделают только хуже.
Обсуждают сегодня