Зачем?
- Когда система становится сложной и содержит много сущностей и запутанностей это приводит к проблеме масштабирования, в едином адресном пространстве во время эксплуатации не возможно понять, что использоваться чаще, что важнее, что больше нагружено.
- Когда понятно какие есть у системы независимые функциональные блоки.
- Когда система распределённая и нам не нужны реляционные связи Базы Данных.
Стратегии декомпозиции
Вот пример найденный с помощью Google-ИИ, а именно паттерны декомпозиции:
Эти паттерны являются ключевыми инструментами для декомпозиции монолита и управления данными в распределенных системах. Они помогают переходить к микросервисам постепенно, минимизируя риски «big bang» миграции.
Паттерны миграции логики
- Strangler (Душитель): Позволяет постепенно заменять части старой системы новыми микросервисами.
- Прокси-слой (Facade/Gateway) перенаправляет запросы: если функционал уже вынесен, запрос идет в микросервис, если нет — в монолит.
- Anti-Corruption Layer (ACL, Предохранительный слой): Слой-посредник, который транслирует модели данных и семантику между старой и новой системами. Он защищает чистоту архитектуры нового сервиса от «загрязнения» устаревшими концепциями монолита.
- Shadowing (Теневое тестирование): Запуск нового кода параллельно со старым на реальном трафике. Результаты сравниваются, но пользователю возвращается ответ от старой системы, что позволяет проверить корректность нового сервиса без риска для бизнес-процессов.
Паттерны работы с данными
CDC (Change Data Capture): Механизм отслеживания изменений в БД через чтение логов транзакций (например, binlog в MySQL). Позволяет почти в реальном времени синхронизировать данные между системами или реализовывать Outbox без лишней нагрузки на приложение.
Dual Read/Write (Двойная запись): Приложение одновременно записывает данные в старую и новую базы данных. Это помогает поддерживать актуальность обеих БД в переходный период, но требует сложной обработки частичных отказов (проблема dual-write).
Outbox (Исходящие сообщения): Решает проблему согласованности при записи в БД и отправке события в брокер (например, Kafka). Событие сохраняется в специальную таблицу outbox в той же транзакции, что и бизнес-данные, а затем отдельный процесс (Relay) надежно доставляет его адресату.
Резюме
Моё предпочтение, как наиболее эффективный способ это
Strangler (Душитель) + Dual Read/Write (Двойная запись) + Outbox (Исходящие сообщения)
Это позволит в сжатые сроки осуществить переход, достаточно радикальная стратегия.
Если система требует 100 процентной надёжности при переходе стоит добавить Shadowing (Теневое тестирование), например финансовая отрасль.