ru:https://highload.today/blogs/ot-ustarevshego-monolita-k-mikroservisam-kak-reshitsya-na-migratsiyu/ ua:https://highload.today/uk/blogs/ot-ustarevshego-monolita-k-mikroservisam-kak-reshitsya-na-migratsiyu/
logo

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

Александр Воробкало BLOG

Lead Software Engineer в UppLabs LLC

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

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

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

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

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

Монолит

Монолит

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

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

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

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

Микросервис

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

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

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

Курс Frontend.
Frontend розробник може легко створити сторінки вебсайту чи вебдодаток. Тому після курсу ви станете затребуваним фахівцем у сфері, що розвивається.
Інформація про курс

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

  • 68% компаний уже используют микросервисы в производстве и разработке;
  • 36% крупных компаний, 50% средних компаний, 44% малых компаний используют микросервисы в производстве и разработке;
  • 26% компаний изучают микросервисы, но еще не начали их внедрять;
  • команды, переходящие на микросервисы, сообщили о 13-кратном увеличении частоты выпусков программного обеспечения.

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

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

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

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

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

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

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

Преимущества монолита Недостатки монолита
При монолитной архитектуре вы можете быстро начать реализацию своей бизнес-логики, вместо того чтобы тратить время и размышлять о взаимодействии между процессами. Медленный процесс разработки: нужно время для каждой функции. Поскольку компоненты работают вместе, их также необходимо менять вместе.
Проще реализовать сквозные (E2E) тесты. Масштабирование может быть проблематичным. Когда одна часть системы требует дополнительных ресурсов, в монолитной архитектуре масштабировать отдельные части системы довольно сложно.
Когда дело доходит до операций, монолит проще развернуть и масштабировать. В монолите практически отсутствует изоляция. Если в модуле возникнет проблема или ошибка, она может замедлить или разрушить все приложение.
Монолит — самый быстрый и относительно недорогой способ создания небольшой системы. Отключение или обновление исходной базы может быть трудным, поскольку необходимо сделать это сразу и для всех частей вашей системы.
Монолитная архитектура удобна для небольших команд. По мере того, как растет кодовая база, качество ухудшается, а IDE  (Integrated development environment — интегрированная среда разработки) постепенно перегружается.
В монолитной архитектуре есть много инструментов, которые вы можете интегрировать, чтобы упростить разработку. _

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

Преимущества микросервисов Недостатки микросервисов
Микросервисы проще сохранять модульными. Технически это можно достичь благодаря жестким границам между отдельными сервисами. В распределенной системе существуют сложности: вам прийдется столкнуться с частичными отказами, более сложными взаимодействиями во время тестирования (E2E) и непростого взаимодействия между сервисами.
Микросервисы меньше по размеру, что способствует быстрому пониманию и тестированию. Большое количество микросервисов поддерживать сложнее, чем несколько экземпляров сигнального монолита.
Нет необходимости координировать развертывание между командами. Лучше развивать сервисы по мере увеличения количества команд. По сравнению с традиционными монолитами, микросервисы могут потребовать больше оборудования.
Меньшие части микросервисов благотворно влияют на продуктивность разработчиков, поскольку позволяют экономить время на ожидание на каждом этапе разработки. Если изменения касаются нескольких сервисов, необходимо координировать их между различными командами, что может быть затруднительно, если команды еще не работали вместе.
Микросервисы не связаны с технологиями, которые задействованы в других сервисах. Для использования новых технологий устаревшие сервисы можно быстро переписать. _
Архитектуру микросервисов легко исправить — вы всегда точно знаете, что именно сломано и в чем проблема.  _

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

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

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

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

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

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

Два решения

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

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

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

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

API Public Getaway

API Public Getaway

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

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

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

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

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

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

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

Результат

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

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

If you have found a spelling error, please, notify us by selecting that text and pressing Ctrl+Enter.

Курс QA Manual (Тестування ПЗ мануальне).
Навчіться знаходити помилки та контролювати якість сайтів та додатків.
Записатися на курс

Этот материал – не редакционный, это – личное мнение его автора. Редакция может не разделять это мнение.

Топ-5 самых популярных блогеров февраля

Всего просмотровВсего просмотров
229
#1
Всего просмотровВсего просмотров
229
Всего просмотровВсего просмотров
209
#2
Всего просмотровВсего просмотров
209
QA в CodeGeeks Solutions
Всего просмотровВсего просмотров
156
#3
Всего просмотровВсего просмотров
156
Senior Project Manager at Nemesis
Всего просмотровВсего просмотров
99
#4
Всего просмотровВсего просмотров
99
Software Architect at Devlify
Всего просмотровВсего просмотров
95
#5
Всего просмотровВсего просмотров
95
Рейтинг блогеров

Ваша жалоба отправлена модератору

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: