От монолита к микросервисам: как мы чуть не сломали себе облачную платформу
Изображение: Shutterstock.ai
При микросервисной архитектуре межсервисное взаимодействие растет. Но снижается связность. Обновление и отладка отдельного сервиса стали проще. А отладка всей системы в целом — сложнее.
В этой статье я хочу поделиться опытом перехода с массивного монолита на гибкие микросервисы и рассказать, в чем он заключается, каковы преимущества данного типа архитектуры и как избежать наших ошибок при переходе.
Что нас подтолкнуло к переходу на микросервисы?
Наш собственный кейс начинается с того, что при создании облачного хранилища с инструментами для обработки контента мы столкнулись с необходимостью масштабирования.
В 2012-м мы разработали объектное хранилище для управления медиафайлами. Чтобы быстро запустить сервис и удовлетворить потребности наших клиентов, использовали монолитный тип архитектуры. Такая модель казалась наилучшим решением, а самое главное — быстро реализуемым.
По мере роста задач и количества клиентов стало очевидно, что старая архитектура не справляется с нагрузкой. Поскольку наша система состояла из различных сервисов, связанных общей БД, то и любые изменения требовали перезапуска всех сервисов, что было особенно проблематично для работы транскодера.
С увеличением числа клиентов мы также столкнулись с проблемами производительности. Эта модель, известная как «распределенный монолит», превратилась в сущий кошмар. Тогда мы приняли решение о переходе на микросервисы, чтобы разделить сервисы и прийти к понятному управлению всей системой.
Немного о том, что такое микросервисная архитектура
Микросервисы — это архитектурный и организационный подход к разработке софта, разделяющий ПО на небольшие независимые сервисы, которые взаимодействуют по заранее прописанным API.
Плюсы микросервисной архитектуры включают:
- масштабируемость (каждый микросервис может масштабироваться независимо, не влияя на производительность других сервисов);
- гибкость (по сути, микросервисы «развязаны» друг от друга, что позволяет разрабатывать, изменять, внедрять новые функции и обновлять их независимо друг от друга);
- отказоустойчивость (если один из сервисов выйдет из строя, ваше ПО продолжит работать);
- технологичность (архитектура позволяет использовать разные технологии для каждой функции);
- постоянная доступность (с этой моделью вы сможете быстрее и чаще выпускать обновления и новые функции, не затрагивая всю систему).
Далее я расскажу о процессе перехода, проблемах, с которыми мы столкнулись.
Эволюция нашей системы хранения данных
Для нас переход к микросервисной архитектуре потребовал серьезной переработки всей системы. Нам пришлось разложить нашу «слитую воедино» структуру на маленькие компоненты.
Цель проекта — переработать облачное хранилище так, чтобы его можно было легко обслуживать, сохранив при этом обратную совместимость. Каждая функция должна стать независимой, с прописанным функционалом и собственной БД.
Итак, мы выделили сервисы для работы с профилями пользователей, транскодирования видео и потоковой передачи данных. А самое главное — избавились от использования общей БД между сервисами.
Начали мы с определения основных компонентов системы и рефакторинга. Мы зафиксировали API для клиентов, и пользователи могли обращаться к старому интерфейсу, пока мы разрабатывали новые функции.
Эффективно очищать хранилище нам помогло внедрение сервиса в качестве «уборщика мусора». Дополнительно мы проработали API Gateway для управления внешним доступом к сервисам.
Преимущества и недостатки перехода на микросервисы
Микросервисная архитектура не является универсальным решением для всех проблем разработки, но для нас она стала ключом к созданию гибкой и масштабируемой системы, способной эффективно обрабатывать огромные объемы медиафайлов.
В итоге у нас получилась гибридная система, которая отлично подходит для наших «жирных» сервисов. Каждый сервис действовал по отдельности, и стало проще обновлять конкретные функции.
Однако связность в микросервисной архитектуре уменьшилась, вдобавок имелись проблемы с синхронизацией. Теперь, чтобы что-то «спросить», сервисы по сути «ходят» друг к другу. Изолированные сервисы работают самостоятельно со своей базой, и их бывает сложно синхронизировать.
Из плюсов — накладные сетевые расходы.
Из минусов — в момент перехода ваш бизнес будет притормаживать. Изменение архитектуры — сложный и долгий процесс, поэтому приготовьтесь, вам предстоит привести в порядок всю техническую часть тех сервисов, которые вы делали зачастую наспех при создании монолита.
Что мы в итоге получили с микросервисами?
Переход осуществлялся из монолитной структуры неспешно, так как мы тестировали все на каждом этапе, чтобы максимально сократить взаимодействие между сервисами.
В итоге микросервисная структура оправдала себя по следующим причинам:
- Обслуживание, обновление и отладка отдельных сервисов стали более удобными.
- Мы смогли масштабировать отдельные компоненты приложения независимо от других.
- Это открыло больше возможностей для разработки инструментов с использованием разнообразных технологий.
- Разработчики могли одновременно работать над различными сервисами, ускоряя процесс разработки.
- Система стала более устойчивой к отказам за счет изоляции служб. Новый дашборд, функционирующий с нашим усовершенствованным API, позволил обращаться клиентам напрямую к каждой БД. Теперь работа с сервисами не требовала перезапуска всей системы.
Вот так все сервисы нашего облачного хранилища стали атомарными.
Выводы
В результате перехода к микросервисной архитектуре мы в Platformcraft минимизировали взаимодействия между сервисами, снизили вероятность возникновения сбоев, а также упростили управление метаданными и объектами. Все это вкупе улучшило производительность и удобство использования системы как для нас, так и для наших клиентов.
Монолитные приложения хоть и быстро запускаются, становятся неприспособленными к масштабированию и изменениям. Если у вас схожая история и вы страдаете от монолита, то переходите на микросервисы.
Для перехода:
- Проведите технический и бизнес-анализ.
- Определите части системы, которые следует «переработать» в микросервисы.
- Разбейте сам монолит на микросервисы (постепенно разделяя функциональность внутри монолита или создав независимые копии сервисов и работая уже с ними)
- Создайте собственные специализированные БД под микросервисы.
- Обеспечьте межсервисную связь.
- Протестируйте и развертывайте.
Правильное планирование, выбор инструментов и языков программирования, а также формирование сильной команды позволит вам преобразить устаревшую систему в масштабируемую, гибкую и производительную архитектуру. Удачи!
Опубликовано 30.04.2024
