Модернизация банковской системы: от монолитной архитектуры к микросервисам

О клиенте

Клиент — разработчик IT-решений для банков и финансовых организаций. В составе объединённых проектных команд работает с крупнейшими банками России. Один из таких проектов — масштабная трансформация клиентских цифровых сервисов для крупного федерального банка.

Проблема и задачи

На момент старта проекта основная система заказчика представляла собой монолитные Java-приложения для обслуживания физических и юридических лиц. Монолит включал десятки взаимозависимых модулей, почти весь бизнес-процесс работал в рамках одного приложения.

Проблемы:

1. Сложность сопровождения и масштабирования. Любое изменение требовало пересборки и развёртывания всего монолита. Это увеличивало время на тестирование и затрудняло развитие отдельных функций. С ростом нагрузки производительность снижалась, особенно в периоды пиковых обращений клиентов.

2. Низкая отказоустойчивость. Монолит не позволял локализовать сбои. Ошибка в одном модуле могла вывести из строя весь клиентский контур, включая мобильное приложение и веб.

3. Долгий релизный цикл. Обновления выходили раз в 4-5 недель. Все изменения поставлялись единым пакетом, что усложняло тестирование и повышало риски при выкатке. Быстрое реагирование на фидбек было невозможно.

4. Отсутствие гибкости в выводе функциональности. Новые функции было трудозатратно включать для отдельных сегментов пользователей. A/B-тесты, гипотезы и поэтапные релизы — технически реализуемы, но крайне затратны.

Чтобы ускорить выпуск новых функций, повысить отказоустойчивость и масштабируемость, было принято решение перейти на микросервисную архитектуру с полной перестройкой backend-сервиса под современные требования.

Задачи:

• Разделить монолит на независимые микросервисы без нарушения клиентского обслуживания.
• Обеспечить возможность масштабирования функциональности горизонтально (по микросервисам).
• Ускорить выпуск новых версий и дать возможность поэтапного вывода фич в прод.
• Синхронизировать изменения с мобильной разработкой: чтобы новые микросервисы полноценно обрабатывали запросы от мобильного клиента, минуя старый монолит или используя его минимально.

Сложность проекта усилилась тем, что часть функциональности была критичной и высоконагруженной: авторизация, история транзакций, работа со вкладами и платежами, витрина продуктов, СБП. Перенос требовал не просто переписывания кода, а проектирования архитектуры заново.

Решение

Мы решили эту задачу, синхронизируясь с архитекторами заказчика и проектируя микросервисную модель поэтапно — с плавным выводом функциональности на прод и стабильной поддержкой существующих клиентов. Все новые сервисы создавались с нуля — по возможности изолированно от монолита, по согласованным архитектурным схемам.

Совместно с архитекторами заказчика мы определяли, какие части старой системы можно безопасно вынести, чтобы не перегружать уязвимый монолит. Для каждого микросервиса на входе мы получали описание архитектуры, ожидаемую бизнес-логику и требования к взаимодействию с внешними системами. На выходе — наша команда брала на себя полный цикл: проектирование, реализация, подготовка профилей нагрузочного тестирования и обслуживание дефектов.

Функциональность, которая была вынесена в отдельные сервисы:

• Брокерское обслуживание
• Рекламные предложения и витрина продаж
• Навигация внутри мобильного приложения
• Кредитные заявки
• СБП
• История транзакций
• Вклады и накопительные счета
• Обслуживание действующих продуктов
• Авторизация и доступ к функциям

Параллельно с разработкой микросервисов разработчики обучали мобильное приложение получать данные не из монолита, а из новых точек входа.

Поддержка высокой нагрузки

Совместно с банком внедрили нагрузочное тестирование, максимально приближенное к прод-среде. Проверяли устойчивость системы при пиковом потоке (до 6 млн пользователей). Возникшие проблемы оперативно устранялись на уровне архитектуры и реализации микросервисов.

Управление фичами и безопасный релиз

Отдельный микросервис отвечает за то, какая функциональность доступна конкретному клиенту. Новый подход позволил включать фичи выборочно — например, только для сотрудников или ограниченной группы клиентов. Это снижает риски: если гипотеза не подтверждается, функциональность можно быстро отключить.
Ранее подобное было технически возможно, но ресурсоёмко — каждый релиз приходилось собирать и выкатывать целиком.

Благодаря этому появилась возможность выпускать новые функции поэтапно:

• Сначала — для опытной группы.
• Затем — на часть пользователей.
• После успешной обкатки — на всю клиентскую базу.

Обновлённый процесс развёртывания

Переход на CI/CD (непрерывную интеграцию и непрерывное развертывание) существенно изменил процесс выпуска новых версий системы. Раньше обновления требовали ручного вмешательства: администраторы или инженеры должны были вручную загружать и настраивать код на серверах, что занимало много времени и создавало риск ошибок.

Теперь все этапы — от интеграции нового кода, его автоматического тестирования до развертывания на разных окружениях — выполняются автоматически. Это значит, что после того, как разработчики загрузили изменения, система сама собирает сборку, прогоняет тесты и выкатывает её на несколько тестовых контуров (в нашем случае их четыре).

Гибкая маршрутизация между старой и новой архитектурой

Там, где не удавалось сразу отказаться от старого монолита, использовался входной сервис на базе NGINX. Он определял, к какому окружению направлять запрос: если мобильное приложение старого формата — в монолит; если новое — в микросервисы.

Результат

• Время выхода новой функциональности — сократилось с месяца до 1–2 недель.
• Обновления происходят без полной остановки системы.
• Команды выпускают код через CI/CD в полуавтоматическом режиме: развёртывание на тестовые окружения — по кнопке.
• Мобильное приложение подключено к микросервисам, а не к монолиту.
• Повысилась стабильность и отказоустойчивость: сбой одного сервиса не влияет на работу остальных.
• Появилась возможность A/B-тестирования новых функций без риска на проде.

Сравнение старой и новой архитектуры

Стек

Технологии до перехода:
JetBrains IntelliJ IDEA, Oracle SQL Developer, Fiddler, Postman, Java SE, PostgreSQL, Oracle Database, React, Redux

Технологии после перехода:
Java 17+, String Boot, liquibase, Kafka, PostgreSQL, docker, CI/DI, GitLab, React