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