Монолит и микросервисы: как выбирать архитектуру под задачи продукта

В монолитной архитектуре интерфейс, бизнес-логика и другие компоненты собраны в общей кодовой базе. Такой подход упрощает начало работы: команде не нужно сразу организовывать взаимодействие множества сервисов.

Что удобно на старте

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

Что может усложниться с ростом

• Масштабирование приложения приходится рассматривать целиком, даже если нагрузка растёт только в одной части.
• Изменение отдельного модуля может требовать общей сборки и развёртывания.
• Увеличение объёма кода и данных повышает требования к управлению зависимостями и производительности.

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

Ниже — возможности этого подхода. Их результат зависит от границ сервисов, связей между ними и организации эксплуатации.

В исходной статье выделены три ситуации, в которых имеет смысл рассмотреть отдельные сервисы:

В видеоплатформе можно выделить несколько областей ответственности. Их разделение имеет смысл, если команды должны независимо развивать функции и управлять нагрузкой.

Аккаунты пользователей. Аутентификация, авторизация, профили, предпочтения и история просмотра. Отдельный компонент позволяет обновлять эти функции через согласованный интерфейс.

Видеокаталог. Фильмы, сериалы и программы, их метаданные, доступное качество и ограничения показа по регионам. Потребность в отдельном масштабировании такого компонента зависит от нагрузки.

Аналитика и рекомендации. Сбор сигналов о поведении и предпочтениях, анализ данных и подбор контента. Алгоритмы персонализации можно развивать отдельно от управления каталогом.

Платежи и подписки. Взаимодействие с банками и платёжными шлюзами, обработка платежей и состояние подписки. Для такой границы важны согласованные контракты и требования к безопасности.

Это один из способов описать функции продукта. Он не доказывает, что конкретная платформа использует именно такие микросервисы, и сам по себе не гарантирует отказоустойчивость или ускорение.

Что на самом деле проверял Netflix Prize. В 2006 году Netflix объявил конкурс с призом в миллион долларов за улучшение точности прогноза пользовательских оценок фильмов. В официальном техническом блоге Netflix задача названа movie rating prediction. Предсказать оценку фильма и предсказать, какой фильм человек посмотрит, — разные задачи. История конкурса иллюстрирует работу над рекомендациями, а не подтверждает устройство микросервисной архитектуры.

В музыкальном сервисе можно выделить пять областей ответственности. Их реализация отдельными сервисами — архитектурное решение команды, которое зависит от масштаба продукта и связей между функциями.

Пользователи и аккаунты. Регистрация, вход, профили, история прослушивания и доступ к пользовательским данным через API. Здесь определяют правила доступа и защиты данных.

Музыкальный каталог. Треки, альбомы и исполнители, их метаданные, обновление и индексация каталога, доступ к аудиофайлам для воспроизведения.

Рекомендации и персонализация. Анализ истории прослушивания, предпочтений и поведения для подбора плейлистов, артистов и треков.

Платежи и подписки. Обработка транзакций, управление статусом подписки и взаимодействие с платёжными системами.

Аналитика и мониторинг. Данные о работе и использовании платформы, наблюдение за производительностью, поиск проблем и оценка изменений инфраструктуры.

Такая модель помогает обсудить ответственность компонентов и границы команд. Она не является подтверждённой схемой «Яндекс.Музыки»: надёжность, скорость и возможность независимых выпусков зависят от конкретной реализации и эксплуатации.

Сервис «Управление SPA-салонами» Riders первоначально разработали как монолит. По мере роста проекта потребовалась большая гибкость развития и управления нагрузкой, и команда занялась переходом к микросервисной архитектуре.

Подробности проекта находятся под NDA. Поэтому в исходной статье описаны только общие роли сервисов, характерные для таких систем:

• Запись клиентов: создание, перенос и отмена записей на услуги. Отдельные экземпляры могут обслуживать разные салоны.
• Букинг: доступные услуги и временные интервалы, бронирования, синхронизация расписаний сотрудников.
• Карточка клиента: контактные данные, история посещений, предпочтения и прошлые записи; интеграции для анализа и персонализации.

Переход строился поэтапно:

Определили, какие части монолита можно выделить, и составили план перехода.

Разработали отдельные сервисы и связали их с существующими компонентами.

Протестировали новую архитектуру и внедрили сервисы в рабочую среду.

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

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

Riders разрабатывает и внедряет проекты с микросервисной архитектурой. В разговоре о вашем продукте начнём с задач, нагрузки и ограничений, чтобы определить, какое разделение действительно необходимо.