Монолит и микросервисы в ecommerce: что выбрать и когда

В чём разница между монолитом и микросервисами

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

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

Термин закрепился после статьи Мартина Фаулера и Джеймса Льюиса «Microservices» в марте 2014 года. Идея старше: ещё закон Конвея 1968 года гласит, что архитектура системы повторяет структуру общения в организации.

Монолит или микросервисы: сравнение по главным параметрам

Как ecommerce прошёл путь от коробки к сервисам

Когда я начинал, нормой считалось развернуть коробку для интернет-магазина и плавно её дописывать. Даже крупные игроки вроде Эльдорадо и Hoff запускались на Битриксе. Нагрузки были маленькими, правила игры проще.

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

Почему гибрид встречается чаще чистых схем

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

У этого приёма есть имя — паттерн Strangler Fig, который Фаулер описал в 2004 году. Новые сервисы постепенно оплетают старую систему, как фикус-душитель дерево, пока монолит не становится маленьким ядром.

Когда монолит выигрывает

Для большинства магазинов хорошо организованный монолит дешевле и быстрее. Фаулер в заметке «MonolithFirst» 2015 года советовал начинать именно с него и дробить систему, когда станут видны границы модулей.

Показательный случай — Amazon Prime Video. В 2023 году команда сервиса мониторинга видео перевела его с распределённой схемы на монолит и, по собственному отчёту, снизила затраты на инфраструктуру на 90%.

Shopify тоже живёт на модульном монолите на Ruby on Rails: код поделён на компоненты с жёсткими границами, но выкатывается одним приложением.

Признаки, что пора дробить

• Релиз одной функции блокирует работу нескольких команд.
• Отдельная часть, например поиск или расчёт цен, требует в разы больше ресурсов, чем остальное.
• Сборка и тесты идут больше часа, и разработчики ждут результата дольше, чем пишут код.
• Разные модули нужно обновлять с разной скоростью.

Цена микросервисов, о которой забывают

Распределённая система требует инфраструктуры: оркестрации в Kubernetes, централизованных логов, трассировки, мониторинга и отдельного DevOps-инженера. Без этого десять сервисов превращаются в десять мест, где может спрятаться ошибка.

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

Третья статья — сеть. Вызов функции внутри монолита занимает микросекунды, сетевой запрос между сервисами — миллисекунды и может не дойти вовсе. Поэтому в каждом сервисе нужны таймауты, повторные попытки и защита от каскадных отказов, например паттерн Circuit Breaker.

Модульный монолит как компромисс

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

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

Для PHP-проектов на Laravel или Symfony это решается структурой пакетов и правилами зависимостей. Проверить, что модули не нарушают границы, помогают статические анализаторы вроде Deptrac.

Ошибки перехода

• Делить систему по техническим слоям, а не по бизнес-доменам.
• Оставить общую базу данных для всех сервисов и получить распределённый монолит.
• Начать дробление без мониторинга и трассировки.
• Перейти ради моды, когда узкое место — медленные запросы к базе, которые лечатся индексами и кешем.

Composable: следующий шаг после спора

Пока команды спорят, что лучше, рынок пошёл дальше. В ecommerce появились готовые системы с бизнес-функциями — PBC, Packaged Business Capability. Поиск, PIM, OMS, промо и лояльность покупают у вендоров и подключают как кубики.

Одних умных поисков на российском рынке уже больше трёх, хотя весь этот рынок оценивается примерно в 300 млн рублей в год. Классов таких систем больше 15, а самих систем — несколько сотен. Десять лет назад ElasticSearch разворачивали сами, сегодня соответствовать ожиданиям покупателей — это сотни часов разработки.

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

Что остаётся своей разработке

Заказной разработки становится меньше, но работы хватает. Кто-то должен сопровождать core-систему, которая оркестрирует интеграции, обеспечивает graceful degradation и делает пользовательский опыт бесшовным.

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