Переход от монолита к микросервисам в финтех: практический кейс
Переход к микросервисам помогает многим компаниям решать проблемы кастомизации и легче масштабироваться. В итоге это может стать важным шагом для создания более конкурентоспособного продукта.
В чем же основная проблема монолитов? При монолитной архитектуре мы создаем единое приложение, в котором все компоненты интегрированы в один блок. Чтобы внести изменений, приходится пересобирать и развертывать его целиком. Это снижает гибкость и оперативность. При таком подходе все части зависят друг от друга, поэтому масштабировать проект сложнее, как и изменять его.
Когда используется микросервисная архитектура, приложение разбивается на отдельные части. Каждый сервис занимается своей задачей, это значит, что вносить изменения можно быстро и точечно.
В этой статье мы расскажем, как приняли решение о переходе и рассмотрим, как к нему подготовиться и успешно осуществить.
Ограничения исходной монолитной архитектуры
Итак, дано: платформа для создания программ лояльности — изначально для разработки мы использовали традиционную модель. Основная проблема была в том, что из-за отсутствия грамотного проектирования и из-за сложной бизнес-логики в приложении, в коде было много ошибок. Постепенно это привело к микроменеджменту и постоянной смене разработчиков бэкенда.
Были и другие сложности:
1. Сложности при внесении изменений
Из-за тесной связанности всех компонентов, даже небольшие изменения в программе лояльности могли вмешаться в бэкенд, вызывая сбои в работе всей платформы.
2. Длительные тестирования
Внесение изменений в монолитные системы требовало длительных и глубоких тестов, это замедляло процесс разработки и внедрения новых функций.
3. Низкая производительность
Оптимизация в монолитных системах — задача непростая, а это влияет на скорость развития продукта в целом.
4. Проблемы кастомизации
Предположим, клиенту нужна возможность добавлять бонусы за рекомендации друзей. Для этого нам пришлось бы внести изменения не только в базу данных рефералов, но и в код для расчета бонусов, а также в пользовательский интерфейс.
Планирование и подготовка к переходу
Прежде чем начать миграцию, мы занялись ее подготовкой — в первую очередь оценили готовность бизнеса и технологического стека. Это включало в себя несколько этапов.
Перед миграцией мы провели детальный анализ требований и сформировали понимание, как они соотносятся с текущими бизнес-процессами. Затем был выбор инструментов (инфраструктура: Docker, Kubernetes, Istio), внешний API и т.д.)
После этого перешли к интеграции с текущим стеком. Убедились, что переход к новой архитектуре не приведет к конфликтам с уже существующим стеком. И, конечно, работали с командой: распланировали обучение и подготовку, которые могли потребоваться для внедрения микросервисов.
Весь процесс подготовки к переходу на микросервисы занял около года.
Domain-Driven Design и микросервисы
В итоге мы остановились на принципах Domain-Driven Design или предметно-ориентированного проектирования.
В Domain-Driven Design, эксперты из определенной предметной области активно участвуют в процессе разработки, ведь они лучше всех понимают, как работают те бизнес-процессы, которые предстоит моделировать.
Важно отметить, что в процессе общения экспертов и разработчиков формируется, так называемый, ubiquitous language. Это значит, что обсуждение происходит в терминах одного и того же, понятного всем языка.ТЗ и код пишутся на нем же.
Кроме использования единого языка DDD включает и другие принципы, как уже отмечали, это использование терминов предметной области в коде, защита независимости предметной области от других областей, технических аспектов и т. д.
У DDD есть много преимуществ. Во-первых, он упрощает взаимодействие между командами. Благодаря применению ubiquitous language, разработчики и команды маркетинга, например, могут использовать общепринятые и понятные всем термины.
Основные понятия в Domain Driven Design — это домен, поддомен и контекст. Домен — это та предметная область, в которой бизнес зарабатывает свои деньги. В нашем случае это создание программ лояльности. Домен делится на поддомены, обособленные логические процессы, которые взаимодействуют между собой на более высоком уровне. Для нашей платформы это — управления бонусами, обработка транзакций, аналитика, взаимодействие с партнерами и т.д.
Доменная модель и ubiquitous language ограничены контекстом, который в Domain-Driven Design называется bounded context. Он ограничивает доменную модель таким образом, чтобы все понятия внутри него были однозначными, и все понимали, о чём идёт речь.
Использование DDD позволило нам сделать бизнес-логику проекта более гибкой и помогло ограничить зоны ответственности команд и приложений.
Процесс миграции
Итак, после подготовки и планирования, мы начали миграцию. Ниже шаги, которые мы предприняли, чтобы разделить платформу на микросервисы с учетом доменных границ и бизнес-логики.
Трудности перехода на мультисервисы
Одним из самых сложных моментов для нас стало само деление на микросервисы, мы понимали, что если это будет сделано неправильно, то обойдется нам достаточно дорого и исправлять это будет сложно. Избежать такой ситуации помогло использование Domain-Driven Design и тот факт, что на подготовку к переходу, мы выделили достаточное время.
Еще один момент, который важно учитывать, это переходный период между полной готовностью микросервисов и доступностью монолита. Важно не отключать функциональность монолита, до того, как все микросервисы начали отлажено работать.
Результаты и преимущества перехода
Несмотря на основательную подготовку, миграция была непростая, а трудности, с которыми мы столкнулись и которые преодолели, достойны отдельной статьи. Теперь же хочется рассказать про результаты. Итак, чего мы добились в итоге:
1. Увеличили гибкость
Теперь можем внедрять изменения быстрее, поскольку каждый микросервис разрабатывается и обновляется отдельно от других.
2. Повысили масштабируемость
Каждый микросервис масштабируется независимо, это дает возможность более эффективно распределять нагрузки, когда возрастают объемы запросов.
3. Упростили обслуживания системы
Во-первых, изолировали проблемы и теперь их можно решать по отдельности. Во-вторых, упростили тестирование. Каждый микросервис тестируем независимо, благодаря этому сам процесс проходит легче и быстрее.
4. Создали и внедрили стандарты разработки
Мы создали подробную документацию для бизнес-аналитиков, разработчиков и DevOps-инженеров. Для этого использовали формат ASCII doc, дополненный диаграммами Plantuml. Так как теперь мы пользуемся подходом «документация как код», документация остается живым артефактом на протяжении всего цикла жизни продукта.
5. Улучшили качество кода
Благодаря тому, что мы задокументировали стандарты, у разработчиков появилось единое понимание, как организовывать файлы, отступы, комментарии, объявления, операторы и прочее. Код стал заметно чище и понятней.
6. Уменьшили текучку кадров
Команды разработчиков получили больше свободы и ответственности одновременно, это хорошо повлияло на мотивацию и на взаимоотношения внутри команд.
Кроме всего прочего, мы ускорили релиз новых фич и повысили CSI (Customer Satisfaction Index).
Выводы
Хочется отметить, что микросервисы не должны являться самоцелью. Они подходят далеко не всем. В нашем случае переход к микросервисной архитектуре был обоснован, так как монолитная архитектура приводила к проблемам. Как мы уже отмечали, в результате всех изменений нам удалось улучшить продукт технически и с точки зрения бизнеса. Мы улучшили качество кода и снизили рост расходов на поддержку платформы. Бонусом получили более мотивированную команду, так как появился четкий задокументированный регламент и более ясное понимание задач.
