Описание проекта
У нас есть большое legacy-приложение на PHP, которое за годы превратилось в единый монолит. Внутри одной кодовой базы и одной базы данных живут авторизация, биллинг, каталог, уведомления и отчёты. Систему стало тяжело масштабировать под нагрузкой и больно выкатывать: любое мелкое изменение вынуждает переразвёртывать всё целиком, а один медленный запрос тянет вниз даже те функции, которые к нему не относятся. Рискованное «переписывание с нуля» нам не подходит. Нужна аккуратная поэтапная миграция, при которой продукт продолжает работать и приносить деньги на каждом шаге.
Основа работы — анализ до кода. Мы ждём, что вы опишете текущее поведение, выделите чёткие ограниченные контексты и вместе с нами определите, какой модуль безопаснее всего вынести первым. Каждый сервис должен жить за понятным контрактом API, а граница вводиться постепенно, чтобы можно было откатиться, если что-то пойдёт не так. Также нужна асинхронная очередь сообщений, чтобы медленные и всплесковые задачи перестали блокировать пользовательские запросы, и контейнеры, чтобы сервис можно было собирать, тестировать и выкатывать отдельно.
Предложите, пожалуйста, поэтапную дорожную карту, а не один прыжок. Реалистичный для нас план начинается с выделения одного низкорискового контекста, работы его параллельно с монолитом, измерения результата и только потом — движения дальше. Честные компромиссы и понятные объяснения важнее модных слов.
Объём первого этапа:
— Описать текущие модули и выбрать первый контекст для выноса.
— Задать контракт API и подключить его к монолиту через переключатель.
— Ввести очередь сообщений для одного асинхронного сценария.
— Контейнеризировать вынесенный сервис с воспроизводимой сборкой.
Основа работы — анализ до кода. Мы ждём, что вы опишете текущее поведение, выделите чёткие ограниченные контексты и вместе с нами определите, какой модуль безопаснее всего вынести первым. Каждый сервис должен жить за понятным контрактом API, а граница вводиться постепенно, чтобы можно было откатиться, если что-то пойдёт не так. Также нужна асинхронная очередь сообщений, чтобы медленные и всплесковые задачи перестали блокировать пользовательские запросы, и контейнеры, чтобы сервис можно было собирать, тестировать и выкатывать отдельно.
Предложите, пожалуйста, поэтапную дорожную карту, а не один прыжок. Реалистичный для нас план начинается с выделения одного низкорискового контекста, работы его параллельно с монолитом, измерения результата и только потом — движения дальше. Честные компромиссы и понятные объяснения важнее модных слов.
Объём первого этапа:
— Описать текущие модули и выбрать первый контекст для выноса.
— Задать контракт API и подключить его к монолиту через переключатель.
— Ввести очередь сообщений для одного асинхронного сценария.
— Контейнеризировать вынесенный сервис с воспроизводимой сборкой.
Разработка программ Наличные, Банковский перевод
