Почему микросервисы проигрывают хорошему монолиту

1. Сложность разработки: Космический шаттл для поездки в магазин

Микросервисный кошмар:

Представьте, что вы начинаете новый проект, например, систему архивации. Вместо одной кодовой базы вы получаете десяток отдельных репозиториев: сервис приема почты, сервис индексации, сервис поиска, сервис экспорта и так далее. Вам нужно:

• Настроить связь между сервисами (HTTP/gRPC), которая всегда медленнее внутренних вызовов.

• Продумать независимое развертывание каждого сервиса.

• Настроить мониторинг, логирование и отслеживание запросов, которые теперь путешествуют по лабиринту сервисов.

• Создать общие библиотеки, рискуя получить "распределенный монолит" — худшее из обоих миров.

Это как собирать космический шаттл для поездки в соседний магазин. Команда из 5-10 разработчиков будет тратить 50% времени не на функции для бизнеса, а на поддержание этой сложной инфраструктуры.

Модульный монолит — элегантное решение:

Одна кодовая база. Одна система контроля версий. Запустили приложение — и все модули работают вместе. Добавили новый тип фильтра в поиск? Он сразу доступен в модуле экспорта. Это как хорошо организованный офис, где все сотрудники в одном помещении, но у каждого своя зона ответственности. Разработка идет с максимальной скоростью, а сложность контролируема.

2. Надежность: Теория вероятностей против вас

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

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

Предположим, надежность каждого сервиса и сети составляет 99.9%. Для операции "найти и открыть письмо", требующей взаимодействия 4 сервисов (шлюз → поиск → хранилище → индекс), общая надежность составит: 0.999 * 0.999 * 0.999 * 0.999 ≈ 0.996 или 99.6%.

Кажется, что разница невелика? Но это означает, что из 1000 запросов 4 завершатся ошибкой, а не 1. И это в идеальных условиях! На практике отказ любого из сервисов (например, сервиса индексации) приводит к частичной или полной неработоспособности всей системы. Вы меняете одну потенциальную точку отказа на десятки.

Монолит: Единая и предсказуемая надежность

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

3. Производительность и масштабирование: Не все так однозначно

Микросервисы — игра в пинг-понг:

В системе архивации каждый поисковый запрос или операция экспорта превращается в квест. Запрос пользователя путешествует так: входной шлюз → сервис поиска → база индексов → сервис хранения для получения тел писем. Каждый переход — это задержки, преобразование данных и потенциальные сетевые ошибки. Сложный поиск с фильтрами, который в монолите был бы одним эффективным запросом к базе данных, распадается на множество сетевых вызовов.

Монолит-решение — скорость света и простое масштабирование:

Все компоненты работают в одном процессе. Вызовы между модулями — это простые обращения в память.

Производительность: Поиск выполняется одним сложным, но оптимизированным запросом к базе данных. Экспорт — это прямая работа с файловой системой и базой данных.

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

Для 95% проектов такого подхода более чем достаточно. Типичный монолит может комфортно обслуживать десятки и даже сотни тысяч пользователей, особенно если вынести изменяемые данные (базу данных, кеш, файловое хранилище) за его пределы.

А если нагрузка возрастет? Вот где проявляется сила модульного монолита. Когда вы упретесь в пределы масштабирования всего приложения, вы сможете выборочно вынести самый нагруженный модуль (например, полнотекстовый поиск) в отдельный сервис. Поскольку модуль уже имеет четкий интерфейс, эта операция пройдет с минимальными затратами. Вы получаете лучшее из двух миров: простоту монолита и целевое масштабирование микросервисов там, где это действительно необходимо.

4. Надежность и целостность данных: Железобетонная гарантия против "кота Шрёдингера"

Классическая проблема микросервисов в архивации:

Сервис индексации получил сообщение о новом письме, успешно его проиндексировал и добавил в поиск. Но сервис приема по какой-то причине ( сеть, временная недоступность) не смог сохранить исходное письмо в хранилище. Результат: пользователь находит письмо в поиске, но при попытке открыть получает ошибку "Файл не найден". Гарантировать согласованность между исходным письмом и его индексной записью в распределенной системе очень сложно и требует нетривиальных механизмов.

Монолитная надежность:

Операция "сохранить письмо + проиндексировать его" может быть выполнена в рамках одной транзакции базы данных. Либо все успешно, либо все откатывается. Пользователь никогда не столкнется с ситуацией "нашел, но не открыл". Для архива почты, где потеря или противоречивость данных недопустимы, это решающее преимущество.

5. Стоимость владения: Инфраструктура не бесплатна

Микросервисные траты:

• Мощная система оркестрации

• Продвинутый мониторинг и отслеживание

• Системы обмена сообщениями

• Высокие зарплаты инженеров, которые все это будут поддерживать.

Монолитная экономия:

• Может успешно работать на нескольких виртуальных машинах.

• Простой процесс развертывания.

• Стандартный мониторинг (логи, метрики базы данных).

• Разработчики сосредоточены на функциях, а не на инфраструктуре.

Так когда же микросервисы оправданы? (Ответ: редко)

Микросервисы — это не "зло", они решают вполне конкретные проблемы, которые у большинства компаний просто не существуют:

• Огромные команды: Когда над одним продуктом работают 50, 100, 500 разработчиков, и монолит становится узким местом для параллельной работы.

• Разные требования к масштабированию: Когда одна функция (например, анализ писем с помощью искусственного интеллекта) требует в 1000 раз больше ресурсов, чем основной поток приема.

• Необходимость использования разных технологий: Когда для разных частей системы критически нужны разные наборы технологий.

• Жесткие требования к изоляции сбоев: Когда падение не критичной функции не должно выводить из строя всю систему.

Если вы не технологический гигант и не создаете сервис для тысяч независимых клиентов — скорее всего, вы не в этой категории.

Вывод: Архитектурная ясность против архитектурного нарциссизма

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

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

• Максимальную скорость разработки и простоту.

• Высокую надежность, где вероятность отказа не умножается на количество сервисов.

• Простое горизонтальное масштабирование до сотен тысяч пользователей.

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

• Железобетонную целостность данных благодаря транзакциям.

• Низкую стоимость владения и простоту сопровождения.

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