Начните с границ доменов и модульности монолита, затем выделяйте по одному слабо связанному компоненту через стабильный контракт и обратимое переключение трафика.
Постепенный переход монолитного Django‑приложения к микросервисной архитектуре
Начните с границ доменов и модульности монолита, затем выделяйте по одному слабо связанному компоненту через стабильный контракт и обратимое переключение трафика.
Короткий ответ
Что ответить на собеседовании
Подробный разбор
Ответ с пояснениями
Условие
В организации работает крупное Django‑приложение, представляющее собой монолитный кодовый базис объёмом более 500 тысяч строк. С ростом проекта поддержка становится всё более проблематичной. Требуется разработать план постепенного перехода от монолитной структуры к микросервисной архитектуре, при котором влияние на уже существующий функционал будет сведено к минимуму.
Ответ
Начните с границ доменов и модульности монолита, затем выделяйте по одному слабо связанному компоненту через стабильный контракт и обратимое переключение трафика.
Размер кодовой базы сам по себе не доказывает необходимость микросервисов. Сначала найдите проблемные связи, измерьте частоту совместных изменений и определите владельцев данных.
Выберите пилот с понятным API и небольшим количеством транзакционных зависимостей. Закройте прямой доступ к его таблицам, добавьте контрактные проверки, метрики и трассировку. Новые запросы постепенно направляйте в сервис, сохраняя возможность отката. Данные мигрируйте с контролем полноты и однозначным источником истины; не оставляйте бесконтрольную двойную запись. Межсервисные события требуют идемпотентности и согласованной схемы. Следующий компонент выделяйте после оценки эксплуатационной цены первого.