Содержание |
Цифровая трансформация — это серьезная стратегическая задача, переход на новый уровень взаимодействия бизнеса с клиентами и партнерами. И такая задача никогда не решается только разработкой мобильного приложения или веб-сайта. Бизнесу необходимы инструменты, которые решают ключевые бизнес-задачи, предоставляют каналы для коммуникации с пользователем — это сложные системы с развитым бэкендом, работающие с большими данными, взаимодействующие с большим числом внешних сервисов. Мобильное приложение — верхушка айсберга, видимая часть огромной сложной инфраструктуры.
Такая ситуация была в одном из кейсов компании 65apps, специалисты которой создавали мобильное приложение для частных инвесторов. За понятным и простым интерфейсом скрываются месяцы работы команды бэкенд-разработчиков.
Первоначально решение разрабатывалось как простой сервис, в котором начинающие инвесторы могут вкладывать свои средства в несложные биржевые инструменты. В основном речь шла о покупке долей в паевых инвестиционных фондах.
Мобильные приложения напрямую взаимодействовали с внутренней системой заказчика, которая полностью обеспечивала всю логику торговых операций с ПИФами. Это закрытое легаси-решение, вносить в него изменения довольно сложно.
Тем не менее, перед заказчиком стояла задача — сделать конкурентоспособный мобильный сервис биржевой торговли, который может легко развиваться, масштабироваться и выдерживать большие нагрузки.
Думаете невозможно? Верно, на существовавшей на тот момент платформе это было невозможно. Поэтому в 65apps помогли клиенту полностью изменить ИТ-инфраструктуру под новые задачи.
Зачем пилить монолит?
У клиента были работающие мобильные приложения для Android и iOS, а также веб-кабинет. Было принято решение оставить их в существующем виде, и только после того, как будет заменен бэкенд, наращивать их функциональность.
Легаси-решение, которое обеспечивало всю логику работы системы и взаимодействие с биржей, состояло из различных блоков, написанных с использованием разных языков программирования. Попытки что-то изменить в одном блоке, часто приводили к сбоям в других местах. Переписать систему полностью тоже не представлялось возможным. Нужно было заменить ее более гибким решением, не останавливая работу клиентских приложений. На следующих этапах планировалось развивать сам сервис: добавлять функциональность, работу с новыми биржевыми инструментами, переходить на собственный банкинг и подключать дополнительные сервисы.
Самый очевидный вариант — переход на микросервисы.
Для того, чтобы постепенно заменять функциональность текущего решения и не нарушать работу мобильного фронтенда, команда бэкенда написала промежуточное решение.
Фактически, это был сервис проксирования с минимальной бизнес-логикой. Он подменял функциональность «монолитной» системы клиента и ее токены на те, которые будут использоваться в новой системе. Постепенно отключались блоки старой системы, для которых были реализованы микросервисы.
По состоянию на сентябрь 2021 года старое решение не отключено полностью, в работе приложения задействовано несколько процентов его функциональности. Эта часть взаимодействует с мобильным приложением через старое API.
Когда основная часть задач была переведена на микросервисы, промежуточный бэкенд стал работать в обратную сторону, переводя запросы из новой версии системы в старое легаси-решение.
Заменив старую систему на микросервисы специалисты 65apps решили две стратегически важных задачи: повысили отказоустойчивость и упростили дальнейшее развитие сервиса.
Нагрузки и масштабирование
Самые большие нагрузки в этом решении приходятся на сервис авторизации, особенно они возросли после переключения сервиса на собственный банкинг клиента. Также повышает нагрузку кэширование данных при работе с портфелем ценных бумаг.
К этой задаче были привлечены DevOps-специалисты. Систему реализовали на Kubernetes — при повышении нагрузки происходит репликация серверов и дублирование их функциональности.
Новое решение выдерживает порядка 400 тыс. одновременных авторизаций (то есть речь идет об RPS в 60-80 тыс., а это очень большая цифра) и до 20 тыс. одновременных подключений при работе с заявками.
Подключение новых систем
В процессе переноса старой системы на микросервисы добавилась новая задача по реализации в приложении биржевого брокера. Ранее заявки обрабатывались через внешний партнерский сервис, который предоставлял два API: gRPC — для торговли, Rest API — для бэкофиса, операций по открытию счета, просмотру списка операций и т.д.
К этому моменту уже были разработаны фронтовые сервисы для бэкенда, которые занимались обработкой бизнес-логики по торговле со стороны мобильных приложений и веб-кабинета. При этом логика по взаимодействию с биржей была реализована на стороне партнера.
Для того, чтобы подключить брокеридж через собственный банк и работать напрямую с биржей, специалистам 65apps нужно было разработать решение, которое замещало бы функциональность посредника. Для нового решения написали точно такое же API, которое было у партнерской системы и когда оно было готово, переключились на прямое взаимодействие с биржей через собственный банк.
Технологии
Как уже говорилось выше, блоки старого решения были написаны на разных языках, что сильно затрудняло возможность изменений. Кроме того, в системе не было никаких тестов, а значит, после внесения изменений в один из блоков кода, невозможно было проверить работоспособность остальных блоков.
Все новые решения в 65apps пишут на Java, но наличие функциональности, написанной на Go, Scala и даже на C++ ставит под сомнение общее быстродействие сервиса. Например, торговый сервис, ядро всей системы, реализован на C++. Его приходится переписывать полностью. Пока эта задача кажется не самой сложной. API со стороны мобильного приложения содержит три основных метода: получение от биржи лучшей цены по конкретному инструменту в зависимости от объема, формирование заявки на покупку и возврат статуса сделки.
Сейчас работает только торговля рублевыми инструментами, но в ближайшее время брокер подключится к Санкт-Петербургской бирже и в приложение будет добавлена автоконвертация для покупки/продажи валютных инструментов.
Благодаря тому, что новый сервис разрабатывается по микросервисной модели, можно легко добавлять практически любую функциональность в адекватные сроки.
Выводы
Никакой бизнес не сможет без потерь остановить работу одного из каналов взаимодействия с клиентами. Но и лишать себя возможности развития из-за ограничений сложной и устаревшей legacy-системы тоже не стоит. Специалисты 65apps нашли возможность планомерно и поэтапно заменить монолитное решение на более современную микросервисную архитектуру, не прерывая работу сервиса. В результате клиент получил гибкое решение, которое выдерживает высокие нагрузки, легко масштабируется и при необходимости совершенствуется за счет быстрого добавления новой функциональности.
Компания 65apps благодарит своего партнера Rocket Science за участие в проекте и помощь в подготовке статьи.
