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

Разбивать монолит ради моды бессмысленно. Делайте это, когда команда растёт, релизы тормозят друг друга, а пики нагрузки бьют по узким местам. Если у вас 10 тысяч заказов в сутки и один деплой в неделю – монолит честнее.

Где проходят границы сервисов

Сервис строится вокруг бизнес-возможности, а не вокруг таблицы в базе. Для e-commerce естественные границы – каталог, поиск, корзина, заказы, оплата, склад, профиль покупателя, уведомления. Каждый сервис владеет своими данными и не лезет в чужую базу напрямую. Это главное правило, которое отличает настоящие микросервисы от распределённого монолита, где всё связано общей схемой и любой рефакторинг ломает соседей.

Каталог и поиск обычно читают намного чаще, чем пишут, – их выносят первыми и кешируют агрессивно. Корзину держат в быстром хранилище вроде Redis, потому что записи частые, а ценность данных живёт минуты. Оплата требует строгой согласованности и аудита, поэтому её изолируют и обкладывают логированием. Рекомендации – отдельный сервис со своим жизненным циклом и собственной нагрузкой на модели; мы разбирали этот контур в материале про рекомендательные системы.

Связь между сервисами и согласованность

Синхронные REST-вызовы по цепочке убивают надёжность: один медленный сервис тормозит всю цепь. Поэтому критичные операции выносят в асинхронный обмен через брокер – Kafka или RabbitMQ. Заказ оформлен – сервис заказов публикует событие, а склад, оплата и уведомления реагируют каждый в своём темпе.

Платой за независимость становится отказ от мгновенной согласованности. Остаток на складе и статус оплаты какое-то время живут раздельно, и систему проектируют так, чтобы это было допустимо: резервирование товара, компенсирующие транзакции, идемпотентные обработчики. Сквозная целостность данных между сервисами, фронтом и внешними системами – платёжными шлюзами, 1С, CRM, ОФД – держится на единой шине и строгих контрактах API, которые здесь важнее, чем код отдельного сервиса.

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

Что нужно до первого сервиса

Микросервисы дают свободу, но требуют зрелой инфраструктуры. Без неё вы получите десять способов уронить прод вместо одного. Минимальный набор: контейнеризация и оркестрация (Kubernetes), централизованные логи и трассировка запросов, единый мониторинг, автоматический CI/CD для каждого сервиса и API-шлюз на входе. Без распределённого трейсинга отладка инцидента в цепочке из восьми сервисов превращается в гадание.

Контейнеризация, оркестрация и наблюдаемость – это та самая база, которую мы относили к ключевым направлениям в обзоре технологических трендов. Для e-commerce они перестали быть опцией.

Вывод

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