В практике UppLabs мы столкнулись с очень интересным техническим кейсом. У нас был проект с конкретной целью — увеличить производительность приложения при помощи миграции с монолитной системы на новую инфраструктуру микросервисов. Для решения этой задачи наша команда решила применить новый подход.
Но сначала давайте ближе познакомимся с некоторыми техническими терминами, чтобы лучше разобраться в этом кейсе и возникших трудностях.
Монолитная архитектура — это технический подход к созданию приложения с единой базой кода с несколькими модулями. Например, веб-сайта.
Обычно мы можем разделить модули, руководствуясь их техническими или бизнес-характеристиками. Они имеют единую систему сборки для всего приложения и его частей. Модуль состоит из одного исполняемого или развертываемого двоичного файла.
Некоторые компании-гиганты, такие как Etsy, остаются и сегодня монолитными, несмотря на популярность микросервисов. Монолитная программная архитектура подойдет, если у вас еще недостаточно опыта работы с микросервисами, ваша команда находится на ранних стадиях, а продукт еще не прошел проверку временем. Монолит идеально подходит для стартапов, которые хотят как можно быстрее запустить продукт.
Основные характеристики микросервисной архитектуры:
Довольно часто монолитные приложения тяжело масштабировать для обработки интенсивного трафика. Они зачастую требуют дополнительное ПО, например, серверы приложений или базы данных. Такие приложения могут состоять из пяти или десяти миллионов строк кода, которые запускают дополнительное программное обеспечение.
Коммерческое программное обеспечение может быть дороже и сложнее в развертывании по сравнению с программным обеспечением с открытым исходным кодом. Микросервис из 10 000 строк вряд ли так сильно позволит задействовать базовую платформу.
Статистика показывает, что:
При переходе с монолитных приложений на микросервисную архитектуру интеграция сталкивается с некоторыми проблемами. Обычно это означает, что разработчикам нужно восстанавливать прежние версии с нуля. Вот почему весь процесс может привести к таким сложностям:
Главный вопрос: почему люди хотят заменить монолитную архитектуру на микросервисы? Статистика показывает, что между монолитными и микросервисными системами существует значительная разница в производительности, которая достигает 79,2%.
Монолит | Микросервисы |
Типичное монолитное приложение состоит из базы данных, клиентского пользовательского интерфейса и серверного приложения. | Микросервисы в основном получили свое название из-за того, что сервисы здесь меньше, чем в монолитной среде. |
Все части программного обеспечения объединены, так что можно управлять всеми его функциями в одном месте. | В микросервисной архитектуре сервисы, которые связаны слабо, взаимодействуют между собой и таким образом выполняют свои бизнес-задачи. |
Компоненты монолитного программного обеспечения взаимосвязаны и взаимозависимы. | Здесь существует много единиц развертывания. Каждый сервис развертывается независимо друг от друга. |
Монолитные приложения обеспечивают быструю связь между программными компонентами благодаря общему коду и памяти. | Меньшие размеры сервисов помогают, когда дело доходит до времени компиляции, выполнения и времени запуска тестов. |
Преимущества монолита | Недостатки монолита |
При монолитной архитектуре вы можете быстро начать реализацию своей бизнес-логики, вместо того чтобы тратить время и размышлять о взаимодействии между процессами. | Медленный процесс разработки: нужно время для каждой функции. Поскольку компоненты работают вместе, их также необходимо менять вместе. |
Проще реализовать сквозные (E2E) тесты. | Масштабирование может быть проблематичным. Когда одна часть системы требует дополнительных ресурсов, в монолитной архитектуре масштабировать отдельные части системы довольно сложно. |
Когда дело доходит до операций, монолит проще развернуть и масштабировать. | В монолите практически отсутствует изоляция. Если в модуле возникнет проблема или ошибка, она может замедлить или разрушить все приложение. |
Монолит — самый быстрый и относительно недорогой способ создания небольшой системы. | Отключение или обновление исходной базы может быть трудным, поскольку необходимо сделать это сразу и для всех частей вашей системы. |
Монолитная архитектура удобна для небольших команд. | По мере того, как растет кодовая база, качество ухудшается, а IDE (Integrated development environment — интегрированная среда разработки) постепенно перегружается. |
В монолитной архитектуре есть много инструментов, которые вы можете интегрировать, чтобы упростить разработку. | _ |
Преимущества микросервисов | Недостатки микросервисов |
Микросервисы проще сохранять модульными. Технически это можно достичь благодаря жестким границам между отдельными сервисами. | В распределенной системе существуют сложности: вам прийдется столкнуться с частичными отказами, более сложными взаимодействиями во время тестирования (E2E) и непростого взаимодействия между сервисами. |
Микросервисы меньше по размеру, что способствует быстрому пониманию и тестированию. | Большое количество микросервисов поддерживать сложнее, чем несколько экземпляров сигнального монолита. |
Нет необходимости координировать развертывание между командами. Лучше развивать сервисы по мере увеличения количества команд. | По сравнению с традиционными монолитами, микросервисы могут потребовать больше оборудования. |
Меньшие части микросервисов благотворно влияют на продуктивность разработчиков, поскольку позволяют экономить время на ожидание на каждом этапе разработки. | Если изменения касаются нескольких сервисов, необходимо координировать их между различными командами, что может быть затруднительно, если команды еще не работали вместе. |
Микросервисы не связаны с технологиями, которые задействованы в других сервисах. Для использования новых технологий устаревшие сервисы можно быстро переписать. | _ |
Архитектуру микросервисов легко исправить — вы всегда точно знаете, что именно сломано и в чем проблема. | _ |
Давайте рассмотрим наш пример, поскольку он отлично иллюстрирует ситуацию, когда команде пришлось перестроить монолитную архитектуру на микросервисы для решения таких проблем:
На первых этапах визуальная часть проекта выглядела довольно просто:
Команда UppLabs предложила клиенту несколько решений:
Заказчик одобрил второе решение, и команда приступила к его реализации. Во время первого мозгового штурма команда UppLabs проанализировала существующее приложение. Помимо монолита, в проекте клиента были проблемы со структурой кода, поэтому его пришлось переписывать с самого начала.
Наша команда решила внедрить логику в микросервис, создав API Public Getaway, благодаря которому можно было легко общаться обеим сторонам — клиентам существующих проектов и бизнес-клиентам.
Сегодня команда UppLabs реализовала план, поэтому у него такая структура:
Мы уже определили следующий план действий для клиента по масштабированию приложения. Собираемся разработать:
Этапы реализации могут занять около года, но с постоянными релизами на каждом этапе.
Главной задачей для нас было найти решение, которое можно было бы реализовать в короткие сроки и которое позволило бы решить бизнес-задачи клиента. Хотя архитектуру микросервисов можно рассматривать как сложное решение, оно оказалось намного проще с точки зрения потенциальной поддержки и масштабируемости.
Сейчас мы работаем над реализацией плана.
В благословенные офисные времена, когда не было большой войны и коронавируса, люди гораздо больше общались…
Вот две истории из собственного опыта, с тех пор, когда только начинал делать свою карьеру…
«Ты же программист». За свою жизнь я много раз слышал эту фразу. От всех. Кто…
Отличные новости! Если вы пропустили, GitHub Copilot — это уже не отдельный продукт, а набор…
Несколько месяцев назад мы с командой Promodo (агентство инвестировало в продукт более $100 000) запустили…
Пару дней назад прочитал сообщение о том, что хорошие курсы могут стать альтернативой классическому образованию.…