Как не сломать себе продукт, переходя на микросервисы? Расскажем на своем примере
В этой статье я поделюсь нашим опытом: расскажу, что подтолкнуло нас перейти с монолитной на микросервисную архитектуру, какие преимущества и трудности мы испытали, и каким образом новая архитектура помогла нам улучшить систему хранения и обработки медиафайлов.
Почему нам потребовались микросервисы?
В 2012 году мы создали хранилище для контента. Монолитная архитектура идеально подошла под наш запрос: требовался быстрый запуск для удовлетворения запросов наших клиентов.
Поначалу всё было отлично, но с увеличением количества инструментов и самих клиентов, монолитная архитектура начала перегружаться. Любые корректировки в системе вели за собой перезапуск всех компонентов, так как все сервисы были связаны общей базой данных.
Это особенно затрудняло работу нашего сервиса по адаптации видео в несколько качеств.
По мере увеличения числа клиентов производительность ухудшалась, и наша монолитная система стала неуправляемым ночным кошмаром!
Тогда мы решили перебраться на микросервисную архитектуру для улучшения масштабируемости и упрощения процесса управления.
С чем вообще едят «микросервисы»?
Микросервисная архитектура представляет собой разделение программное обеспечение на отдельные «не слитные» сервисы, взаимодействующие через API.
Преимущества этого подхода в следующем:
- Масштабируемость – все сервисы можно масштабировать отдельно.
- Гибкость – возможность независимой разработки, апгрейда и развертывания.
- Отказоустойчивость – отказ одного сервиса никак не повлияет на систему.
- Технологичность – работа с любыми технологиями при разработке функций.
- Доступность – при регулярном выпуске обновлений, решение не прекращает работу.
Как мы сами переехали на микросервисную архитектуру?
Переход с монолитной архитектуры потребовал значительных изменений. Мы разделили нашу монолитную структуру на независимые компоненты, не трогая так называемую «обратную совместимость».
Каждый сервис получил свой функционал и отдельную базу данных.
Основные этапы включали:
- Выделение компонентов и рефакторинга.
- Добавления функции «уборки» для эффективного управления хранилищем и удаления файлов.
- Разработка собственного API для работы с инструментами.
Какие плюсы и минусы микросервисной архитектуры я смог выделить?
Среди преимуществ:
- Удобство обслуживания и работы с выделенными сервисами.
- Независимое масштабирование компонентов.
- Возможность использования различных технологий.
- Ускорение процесса разработки благодаря параллельной работе над сервисами.
- Повышенная устойчивость к отказам.
Среди недостатков:
- Сложность синхронизации изолированных сервисов.
- Увеличение расходов.
- Замедление бизнес-процессов из-за времени на переход.
Подведем итоги
Перенастройка на микросервисную архитектуру была поэтапной с учетом тестов.
В результате новая архитектура оправдала себя:
- Упростилось обслуживание и обновление наших инструментов.
- Масштабирование отдельных компонентов стало проще.
- Расширились вариативность для разработки благодаря различным технологиям.
- Процесс разработки ускорился благодаря одновременной работе над сервисами.
- Повысилась отказоустойчивость всей системы.
Новый дашборд и обновленное API дали возможность для наших пользователей работать с каждой базой данных напрямую, что облегчило в целом взаимодействие с платформой. Вот таким образом наши сервисы стали независимыми и более эффективными.
Надеюсь, статья поможет вам решить – подойдет ли микросервисная архитектура для перехода или нет.