От устаревшего монолита — к микросервисам: как решиться на миграцию

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

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

Монолитная архитектура

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

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

Монолит

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

Микросервисная архитектура

Основные характеристики микросервисной архитектуры:

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

Микросервис

Зачем нужна миграция?

Довольно часто монолитные приложения тяжело масштабировать для обработки интенсивного трафика. Они зачастую требуют дополнительное ПО, например, серверы приложений или базы данных. Такие приложения могут состоять из пяти или десяти миллионов строк кода, которые запускают дополнительное программное обеспечение.

Коммерческое программное обеспечение может быть дороже и сложнее в развертывании по сравнению с программным обеспечением с открытым исходным кодом. Микросервис из 10 000 строк вряд ли так сильно позволит задействовать базовую платформу.

Статистика показывает, что:

• 68% компаний уже используют микросервисы в производстве и разработке;
• 36% крупных компаний, 50% средних компаний, 44% малых компаний используют микросервисы в производстве и разработке;
Курс Fullstack Web Development.
Володій навичками розробки як на фронтенді, так і на бекенді. За такими фахівцями черга в компаніях!
Отримати інформацію про курс
• 26% компаний изучают микросервисы, но еще не начали их внедрять;
• команды, переходящие на микросервисы, сообщили о 13-кратном увеличении частоты выпусков программного обеспечения.

Трудности при переходе на микросервисы

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

• траты времени и денег;
• нет требований или фактического состояния, только код;
• возникновение технических вопросов: о технологиях, подходах, применении на практике.

Монолит VS микросервисы

Главный вопрос: почему люди хотят заменить монолитную архитектуру на микросервисы? Статистика показывает, что между монолитными и микросервисными системами существует значительная разница в производительности, которая достигает 79,2%.

Плюсы и минусы монолита

Плюсы и минусы микросервисов

Реальный кейс UppLabs

Давайте рассмотрим наш пример, поскольку он отлично иллюстрирует ситуацию, когда команде пришлось перестроить монолитную архитектуру на микросервисы для решения таких проблем:

• сервер зависал при количестве активных пользователей более 3000;
• монолитная архитектура не допускала масштабирования;
Курс QA.
Стань неперевершеним QA спеціалістом! Стань технічною хрещеною феєю, яка оберігає від помилок і багів. Використай цей шанс!
Дізнатись про курс
• неоптимизированный код (на бэкенде);
• множество триггеров в базе данных (почти в каждой таблице было по три триггера), которые убивали производительность;
• бизнес-логика в триггерах и хранимых процедурах, C # — в качестве бэкенд-кода;
• было трудно поддерживать устаревший код и добавлять новые функции, которые необходимы бизнесу.

На первых этапах визуальная часть проекта выглядела довольно просто:

Визуализация на первых этапах проекта

Два решения

Команда UppLabs предложила клиенту несколько решений:

1. Переписать приложение с нуля на микросервисную архитектуру и использовать лучшие практики написания кода. На это решение потребовалось бы более года разработки и команда из 5+ человек.
2. Внедрить один микросервис, который покрыл бы небольшую, но наиболее часто используемую часть функциональности, благодаря которой возникают самые большие проблемы с производительностью. На это потребовалось бы около двух месяцев разработки и команда из двух человек.

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

Наша команда решила внедрить логику в микросервис, создав API Public Getaway, благодаря которому можно было легко общаться обеим сторонам — клиентам существующих проектов и бизнес-клиентам.

API Public Getaway

Сегодня команда UppLabs реализовала план, поэтому у него такая структура:

Окончательная структура

Масштабирование

Мы уже определили следующий план действий для клиента по масштабированию приложения. Собираемся разработать:

• еще один микросервис, который будет отвечать за сложную часть бизнес-логики и обработку больших данных;
• дополнительный микросервис, который будет отвечать за управление пользователями;
• микросервис PDF, который будет отвечать за создание файлов;
• почтовый микросервис, который будет работать со списками рассылки и шаблонами.

Этапы реализации могут занять около года, но с постоянными релизами на каждом этапе.

Результат

Главной задачей для нас было найти решение, которое можно было бы реализовать в короткие сроки и которое позволило бы решить бизнес-задачи клиента. Хотя архитектуру микросервисов можно рассматривать как сложное решение, оно оказалось намного проще с точки зрения потенциальной поддержки и масштабируемости.

Сейчас мы работаем над реализацией плана.