Миграция данных из монолита в микросервис (воздушный поток)

Question

У нас есть мультитенантная монолитная система, и мы переходим к архитектуре микросервисов. Мы запланировали извлечь 4 микросервиса, для миграции данных мы добавляем конечную точку отдыха в монолит для извлечения данных и конечную точку в микросервисе для вставки данных. На высоком уровне необходимы следующие шаги.

1. Rest конечная точка в монолите для выборки данных, API будет разбит на страницы с помощью фильтра, такого как tenantId.
2. Обработка данных или преобразование данных.
3. Вставка данных в базу данных микросервиса для микросервиса откроет все остальное endpoint.

Я новичок в потоке данных и хотел бы знать, является ли это жизнеспособным решением. Ниже приведены мои ограничения.

1. Я хочу ускорить копирование данных, например, 10 элементов за один раз, поэтому это не влияет на создание нагрузки на монолит, потому что он также обслуживает живой трафик c.
2. Возможность повторять попытки при сбоях.

После первоначального чтение потока данных, я придумал два варианта

Вариант 1

Я создам DAG для выполнения ETL с двумя задачами Extract и Transform Task: который вызовет API-интерфейс монолита для получения данных, преобразованных и помещенных в корзину S3. Задача загрузки: которая вставляет преобразованные данные

Вариант 2 Только одна задача Извлечение, преобразование и загрузка: ведро S3 не требуется. Получить 10 элементов, преобразовать и загрузить в микросервис.

Я новичок в ETL и потоках данных, поэтому дайте мне знать, какой подход лучше. Также, в случае повторной попытки, есть ли способ создать контрольную точку в воздушном потоке, например, сбой задачи после вставки 100 записей в микросервис. Когда происходит повторная попытка, я не хочу начинать сначала.

Answer 1

Я понимаю, что вы пытаетесь перейти с монолита на микросервисы

1. Элемент списка

Это медленный переход с Monolithi c на Micro- услуги путем распределения трафика c между двумя системами.

или

Полное переключение на новые микросервисы в прекрасный день.

Если это второй подход, я бы сделал ETL для миграции данных.

Если это первый подход -

Внедрить CDC / или просто изменить службу monolithi c на публикацию sh постоянных операций в системе обмена сообщениями (Kafka.Rabbit).

Внедрить подписчика в микросервисы и обновить DB.

Убедившись в реализации Pub / Sub, перенаправьте все операции чтения в систему микросервисов.

Затем медленно перенаправьте некоторый процент постоянных вызовов в микросервисы, которые будут выполнять вызовы отдыха для старая система для обновления старой БД.

Как только вы будете уверены в новых услугах, качестве данных и других требованиях (производительности), полностью переключитесь на новые микросервисы).

** вам необходимо do historyi c syn c перед запуском процесса обмена сообщениями Asyn c.

Это один из способов плавного переключения с Monolithi c на микросервисы.