Монолит или микросервисы: что выбрать для интернет-магазина и когда нужны отдельные сервисы

Монолит и микросервисы — не две последовательные ступени развития, где интернет-магазин сначала работает на «простой» архитектуре, а после определенного размера обязан перейти на микросервисы. Оба подхода могут быть правильными. Выбор зависит от того, насколько независимо должны развиваться части интернет-магазина, как распределена нагрузка, сколько команд работает над системой, насколько сложны интеграции и данные и готова ли компания сопровождать распределенную архитектуру.

Микросервисы позволяют отдельно изменять, выпускать и масштабировать части системы. Но за эту независимость приходится платить дополнительной сложностью: сервисы должны взаимодействовать между собой, согласовывать данные, переживать частичные сбои, а команда — наблюдать за работой уже не одного приложения, а нескольких компонентов. Поэтому вопрос стоит формулировать не как «что современнее», а так: какая архитектура решает реальные задачи интернет-магазина с минимально необходимой сложностью?

Что такое монолитная и микросервисная архитектура

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

Что такое монолитная архитектура

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

В интернет-магазине внутри такого приложения могут находиться:

• каталог;
• поиск;
• цены и акции;
• остатки;
• корзина;
• оформление заказа;
• личный кабинет;
• управление заказами;
• доставка;
• уведомления;
• интеграции с внешними системами.

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

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

Что такое микросервисная архитектура

Если объяснить микросервисную архитектуру простыми словами, систему делят на относительно самостоятельные компоненты с понятной бизнес-ответственностью. Например, в конкретном интернет-магазине отдельными сервисами потенциально могут быть поиск, уведомления или работа с определенной внешней системой. Они взаимодействуют через заранее определенные программные интерфейсы — API.

При правильно выбранных границах отдельный сервис можно:

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

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

Не нужно превращать каждую функцию интернет-магазина в самостоятельный сервис. Сервис «добавить товар в корзину», сервис «удалить товар из корзины» и сервис «изменить количество» не становятся хорошей архитектурой только из-за того, что их много.

Монолит и микросервисы: различия, плюсы и минусы

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

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

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

Принципы микросервисной архитектуры

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

Границы проходят по бизнес-функциям

Сервис должен отвечать за понятную область системы, а не быть произвольным техническим фрагментом. Например, «поиск товаров» — понятная функция. Она получает запрос, применяет правила поиска и возвращает результаты. А разделение только потому, что один класс стал слишком большим, само по себе еще не создает микросервис.

У компонента есть понятная ответственность

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

Связи между компонентами ограничены

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

Независимый выпуск должен приносить пользу

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

Инфраструктура становится частью архитектурного решения

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

Модульный монолит как отдельная архитектурная стратегия

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

Например:

• каталог;
• цены;
• заказы;
• доставка;
• личный кабинет.

Каждый модуль имеет свою ответственность, а взаимодействия между модулями ограничены понятными правилами. Это важно, потому что многие проблемы, которые приписывают монолитной архитектуре, на самом деле возникают из-за высокой связанности кода. Если невозможно изменить цены, не затронув заказы, или удалить старую интеграцию, не исправляя пять других подсистем, проблема может заключаться не в том, что приложение монолитное. Сначала может быть полезнее определить границы модулей и убрать лишние зависимости.

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

Как разные архитектуры выглядят в интернет-магазине

Абстрактное сравнение мало помогает выбрать архитектуру электронной торговли. Посмотрим на один и тот же магазин в трех вариантах.

В нем есть: каталог → поиск → цены → остатки → корзина → оформление заказа → оплата → заказы → доставка → личный кабинет → уведомления → интеграции

Монолитный интернет-магазин

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

Интернет-магазин как модульный монолит

Второй вариант внешне тоже остается одним приложением. Но внутри явно разделены, например: Каталог | Цены | Корзина | Заказы | Доставка | Пользователи

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

Интернет-магазин с отдельными сервисами

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

Например:

• ядро магазина: каталог, цены, корзина, заказ;
• отдельно: поиск;
• отдельно: уведомления;
• отдельно: интеграция с внешней системой.

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

Какие части интернет-магазина имеет смысл выделять отдельно

Не существует универсального списка микросервисов, которые обязательно должны быть в каждом интернет-магазине.

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

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

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

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

Как выбрать архитектуру интернет-магазина

Сравнение плюсов и минусов не дает готового ответа. Для решения нужно посмотреть на конкретный проект.

Новый проект или существующая система

Для нового интернет-магазина есть проблема: реальные границы бизнеса еще могут быть не до конца понятны. Процессы меняются, появляются новые правила, нагрузка отличается от прогнозов. Слишком раннее разделение на сервисы способно зафиксировать границы, которые позже окажутся неудобными. Из этого не следует правило «новый проект всегда нужно делать монолитом». Если бизнес-области давно известны, несколько команд должны развиваться независимо, а требования к отдельным компонентам действительно различаются, сервисная архитектура может быть оправдана и на старте.

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

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

Решение становится основанным не на предположениях, а на наблюдаемой работе системы.

Оцените нагрузку на отдельные части системы

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

Оцените независимость изменений

Задайте несколько вопросов:

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

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

Оцените структуру команды

Популярное правило «после определенного количества разработчиков нужны микросервисы» не работает. Важнее не количество людей, а распределение ответственности. Одна команда, которая совместно работает над всем интернет-магазином, может быстрее развивать хорошо организованный монолит. Если же несколько команд независимо отвечают за каталог, заказы и логистику и постоянно мешают друг другу из-за общей кодовой базы и общего выпуска, самостоятельные архитектурные границы становятся полезнее. Архитектура и структура команды начинают влиять друг на друга.

Оцените требования к устойчивости

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

Представим цепочку: корзина → заказ → резерв товара → оплата → уведомление

Если платежный сервис не ответил, система должна понимать:

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

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

Оцените работу с данными

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

После разделения нужно четко определить:

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

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

Проверьте готовность команды и инфраструктуры

Распределенную систему мало правильно разработать — ее нужно уметь эксплуатировать.

Команде потребуется:

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

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

Сравните полную стоимость архитектур

Нельзя сравнивать решения только по стоимости первоначальной разработки.

Нужно учитывать:

• инфраструктуру;
• тестирование;
• выпуск изменений;
• наблюдение за системой;
• сопровождение;
• работу с инцидентами;
• масштабирование;
• стоимость будущих изменений.

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

Когда микросервисы не нужны

Есть несколько аргументов, которые сами по себе не являются основанием для перехода:

• Большой интернет-магазин. Размер бизнеса не определяет структуру приложения.
• Высокий общий трафик. Монолит тоже можно масштабировать. Сначала нужно определить, какие части системы создают ограничения.
• Старый проект. Возраст кода не говорит о том, какие архитектурные границы ему нужны.
• Большая кодовая база. Большой код может оставаться хорошо структурированным, а небольшая распределенная система — быть сильно связанной.
• Плохой код в монолите. Разделение плохого кода по сети не исправляет его автоматически.
• Планы роста. Нужно понимать, какие конкретные требования рост создаст для системы.
• Микросервисы используют крупные компании. Архитектура другой компании решает ее собственные задачи.

Иногда правильным решением будет привести монолит в порядок:

• разделить его на модули;
• уменьшить зависимости;
• оптимизировать базу данных;
• добавить кеширование;
• переработать конкретное узкое место;
• вынести только одну проблемную функцию.

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

Сервисное разделение становится более обоснованным, когда наблюдается не один аргумент, а несколько конкретных признаков:

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

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

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

Что выбрать: монолит, модульный монолит или микросервисы

Универсального ответа нет, но можно использовать практическую матрицу.

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

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