Микросервисы — не серебряная пуля. Когда старый-добрый монолит — лучшее решение

Всем привет. Я Артём, CTO arcsinus. Наткнулся на статью в HackerNoon о том, что микросервисы — не панацея, и часто вообще не нужны. И знаете что? Какая жиза! Я насмотрелся на проекты, где команды внедряли микросервисную архитектуру потому, что так модно, а потом тихо плакали в углу, потому что это очень сложно поддерживать. Поделюсь своими соображениями о том, когда микросервисы действительно нужны, а когда это дорогая игрушка.

Цена микросервисного «счастья»

Вот математика из моего опыта: микросервисы увеличивает время разработки раза в полтора. И это только начало, затраты, которые можно уверенно закладывать ещё до старта работ.

Помимо очевидных накладных расходов на сетевое взаимодействие, сериализацию и HTTP-оверхед, есть менее заметные, но болезненные проблемы:

1. Инфраструктурная сложность. Вместо одного приложения вы получаете целый зоопарк: контейнеры, Kubernetes, очереди сообщений, RPC, системы конфигурации... Каждый компонент требует настройки, мониторинга и поддержки. У вас есть DevOps-инженер? А лучше два? Нет? Тогда микросервисы — ваш кошмар.
2. API-версионирование. Простого рефакторинга не будет. Теперь каждое изменение интерфейса — это миграция, поддержка нескольких версий API и планирование обратной совместимости. Переименовать поле? Закладывайте несколько месяцев.
3. Отладка становится квестом. Попробуйте найти причину бага, когда запрос проходит через пять сервисов. Без продвинутого трейсинга понадобится целое расследование.

Когда монолит — мудрый выбор

Вопреки расхожему мнению, монолит — не техдолг по умолчанию. Более того, есть сценарии, где он явно выигрывает:

1. PoC (Proof of Concept) и Minimum Viable Product (MVP). Когда нужно быстро проверить гипотезу или выйти на рынок, монолит — ваш друг. Незачем усложнять архитектуру, если бизнес-модель ещё не подтверждена.
2. Малые команды и ограниченные ресурсы. Если у вас команда до 15 человек, микросервисы могут съесть больше времени, чем принести пользы. Лучше сосредоточиться на продукте, а не на инфраструктуре.
3. Проекты с предсказуемой умеренной нагрузкой. Статичные сайты-«визитки», корпоративные системы, любые внутренние инструменты — кандидаты для монолитной архитектуры.

У нас в arcsinus есть проект, где мы сразу пошли по пути модульного монолита. Результат — быстрая разработка, простая отладка и возможность при необходимости выделить отдельные модули в микросервисы.

Модульный монолит: лучшее из двух миров

Если хотите получить преимущества микросервисов, но без многочисленных накладных расходов — рассмотрите архитектуру модульного монолита. Приложение состоит из слабо связанных модулей с чёткими границами, но работает как единое целое. Принцип модульного монолита можно описать следующими тезисами:

1. Каждый модуль решает конкретную бизнес-задачу.
2. Модули взаимодействуют через определённые интерфейсы.
3. Общая база данных, логически разделённая по доменам.
4. Возможность постепенной миграции в микросервисы.

Этот подход даёт 70-80 % преимуществ микросервисов. И когда действительно понадобится масштабирование — миграция пройдёт гораздо проще.

Когда пора переходить на микросервисы

Разместите
тендер бесплатно

Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.

Заполнить заявку 13260 тендеров
проведено за восемь лет работы нашего сайта.

А когда микросервисы действительно оправданы? Вот три ключевых сигнала:

1. Узкие места производительности. Отдельные части системы требуют разного масштабирования. На примере екома — это когда каталог товаров нагружен сильнее, чем система лояльности.
2. Проблемы с параллельной разработкой. Команды постоянно конфликтуют в коде, а каждый релиз превращается в адок.
3. Технологическое разнообразие. Для машинного обучения нужен Python, для высокопроизводительных вычислений — Go, для легаси — Java. Совместить это в монолите сложно.

Если столкнулись с каким-либо из этих сценариев, можно подумать о поэтапной миграции: выделить один проблемный модуль в отдельный сервис, обкатать процессы и инфраструктуру, а затем принимать решение о дальнейших шагах.

Рекомендации

1. Начинайте с простого. Даже если планируете микросервисы в будущем, стартуйте с модульного монолита. Это поможет лучше понять границы доменов.
2. Инвестируйте в архитектора. Микросервисы без продуманной архитектуры превращаются в так называемый «distributed big ball of mud» — худшее из двух миров.
3. Подготовьте команду. Микросервисы требуют зрелых DevOps-процессов, мониторинга и культуры ответственности за результат. Если команда не готова — лучше подождать.
4. Думайте как финдиректор. Каждый микросервис — это дополнительные расходы на инфраструктуру, разработку и поддержку. Убедитесь, что выгода перевешивает затраты.

Что в итоге

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

Помните: архитектура — инструмент бизнеса, а не модный аксессуар. Иногда самое мудрое решение — признать, что вашему проекту пока достаточно хорошо спроектированного монолита.