~2~Обзор проекта ~p~Банковская платформа развивалась вокруг монолитного Java-приложения, обслуживавшего клиентские финансовые сервисы. Любое изменение затрагивало зависимости между бизнес-функциями, затрудняя независимые релизы и масштабирование. Инженерная команда помогла вынести часть функций в отдельно развёртываемые сервисы, сохранив работу привычных банковских сценариев. ~2~Задача ~p~Полная перепись системы поставила бы под угрозу повседневные банковские операции. Платформа должна была продолжать обслуживать клиентов, пока новые сервисы постепенно перенимали функции устаревшего приложения. Требовалось разделить тесно связанную бизнес-логику, сохранить совместимость со старыми версиями приложения и обеспечить более управляемые релизы.

~2~Решение и реализация ~3~Поэтапная миграция вместо одномоментной замены ~p~Совместно с архитекторами заказчика команда определила границы сервисов и создала новые Java-сервисы для отдельных бизнес-функций: истории транзакций, операций со счетами, предложений клиентам и управления доступом. Старые модули оставались в системе до готовности замены. ~3~Маршрутизация между старой и новой системами ~p~Входной слой направлял запросы либо в монолит, либо в новые сервисы в зависимости от версии клиентского приложения. Это позволило старым и новым мобильным интерфейсам сосуществовать во время перехода. ~3~Более надёжное развёртывание ~p~Команда внедрила контейнеризацию, CI/CD и управляемое включение функций. Новая возможность сначала могла включаться для небольшой группы пользователей, а затем распространяться шире, снижая риски одновременного изменения для всех клиентов. ~3~Проверка производительности ~p~Для критичных сервисов подготовили сценарии нагрузочного тестирования. Выявленные узкие места устраняли на уровне приложений и взаимодействия сервисов.

~2~Технические особенности ~3~Поэтапная миграция и обратная совместимость ~p~Переход строился вокруг бизнес-функций, а не механического разделения исходного приложения. Команды выделили сервисы истории транзакций, сберегательных продуктов, клиентских предложений, кредитных заявок, авторизации и других сценариев. Новый входной API выбирал старый или микросервисный обработчик в зависимости от версии мобильного клиента. Это было важно: клиенты обновляли приложение не одновременно, а пользователи старых версий должны были продолжать привычные операции. ~3~Базы данных и организация релизов ~p~Новые сервисы использовали PostgreSQL наряду с функциями на Oracle. Liquibase управлял изменениями схем, типобезопасный SQL-доступ облегчал работу с новыми моделями данных. Развёртывание в Kubernetes разделяло запуск и масштабирование по сервисам. Автоматизированные сборки и тесты охватывали несколько сред, а новые возможности можно было сначала открыть ограниченной группе клиентов. ~p~Команда подготовила реалистичные профили нагрузки для банковских операций и исследовала узкие места в сервисах и доступе к данным. Это критично для входа в приложение, истории счетов и других функций, которые нельзя отключить на время миграции. ~3~Особенности реализации ~p~Миграция выполнялась по бизнес-доменам: авторизация, транзакции, платежи, вклады и клиентские предложения переносились в независимые сервисы, а старые версии клиента временно продолжали работать с монолитом. ~p~Маршрутизация запросов между старым и новым контурами выполнялась через NGINX. Kubernetes, GitLab CI/CD, Java 17, Spring Boot, PostgreSQL, Liquibase и Kafka относятся к подтвержденному стеку проекта. ~p~Выборочный выпуск функций позволил тестировать изменения на ограниченной аудитории и при необходимости быстро отключать их. ~2~Результат ~p~Новые банковские функции, которые раньше доставлялись пользователям примерно за четыре-пять недель, стали выпускаться за одну-две недели. Команды получили независимые развёртывания, постепенный запуск функций и маршрутизацию современных клиентов в новые сервисы при поддержке старых версий. Сбой одного сервиса перестал обязательно затрагивать несвязанные части платформы. Кроме того, банк мог проверять и откатывать клиентские изменения без повторного развёртывания всего монолита.