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

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

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

Когда монолит становится узким горлышком

Монолитная архитектура отлично работает на старте: один репозиторий, одна база данных, простой деплой. Проблемы начинаются, когда:

• Нагрузка растёт — сервер не справляется, а горизонтальное масштабирование всего приложения дорого и неэффективно (например, кеш Redis для корзины не помогает, если «тяжёлый» поиск грузит CPU).
• Команда разработки >10 человек — merge-конфликты, долгие CI/CD, зависимость релизов друг от друга.
• Требуется часто обновлять отдельные модули (например, платёжный шлюз меняется раз в месяц, а каталог — раз в квартал).
• Нужна разная технология для разных частей: поиск на Elasticsearch, корзина на Node.js, админка на PHP.

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

Протоколы и инструменты обмена данными между сервисами

Ключевой вопрос — как сервисы общаются друг с другом. В нашей практике (AVOdigital) мы используем комбинацию синхронных и асинхронных протоколов.

1. REST API (синхронный)

Базовый протокол для прямых запросов. Например, сервис корзины запрашивает у сервиса каталога цену товара. Используем JWT (JSON Web Token) для аутентификации между сервисами. Настройка Nginx для проксирования:

location /api/catalog/ { proxy_pass http://catalog-service:8080; proxy_set_header Authorization $http_authorization; proxy_set_header X-Real-IP $remote_addr;
}

2. CommerceML (асинхронный обмен с 1С)

Для интернет-магазинов часто нужен обмен с 1С. CommerceML — стандарт, но в микросервисах его лучше вынести в отдельный сервис-адаптер, который принимает XML, валидирует и публикует события в RabbitMQ. Пример настройки .htaccess для ограничения доступа к эндпоинту обмена:

RewriteEngine On
RewriteCond %{REMOTE_ADDR} !^192\.168\.1\.
RewriteRule ^exchange/1c/ - [F]

3. Асинхронная шина (RabbitMQ / Redis Pub/Sub)

Для событий, не требующих мгновенного ответа (отправка письма, обновление поискового индекса, списание бонусов). Используем RabbitMQ с топиками: order.created, payment.confirmed. Сервисы подписываются и обрабатывают независимо. Redis используем для кеша сессий и временных данных (корзина неавторизованного пользователя).

4. OAuth 2.0 / JWT для единой аутентификации

В микросервисах нельзя полагаться на сессии PHP (файлы или wp-config.php с настройками). Внедряем централизованный сервис аутентификации (SSO) на OAuth 2.0. JWT-токен содержит ID пользователя и роли, каждый сервис проверяет подпись публичным ключом. Пример проверки в Nginx через auth_request:

location /api/private/ { auth_request /auth; proxy_pass http://backend;
}
location = /auth { internal; proxy_pass http://auth-service:9000/validate; proxy_pass_request_body off;
}

Таблица сравнения: монолит vs микросервисы для интернет-магазина

Пошаговый чек-лист перехода от монолита к микросервисам

На основе проектов AVOdigital (например, миграция интернет-магазина с 50 000 SKU) мы выработали следующий план:

1. Аудит монолита. Выделите «горячие» модули: поиск, корзина, личный кабинет, админка. Замерьте latency, количество запросов, частоту изменений.
2. Выберите первый сервис для выноса. Обычно это поиск или корзина — они наиболее нагружены и слабо связаны с остальными.
3. Определите контракты. Опишите REST API (OpenAPI/Swagger) или gRPC. Укажите формат данных (JSON/Protobuf), версионирование (/v1/).
4. Настройте инфраструктуру. Поднимите Docker-контейнеры, Nginx как API Gateway, Redis для кеша, RabbitMQ для событий. Пример docker-compose.yml для RabbitMQ:

version: '3'
services: rabbitmq: image: rabbitmq:3-management ports: - "5672:5672" - "15672:15672" environment: RABBITMQ_DEFAULT_USER: admin RABBITMQ_DEFAULT_PASS: secret

1. Реализуйте аутентификацию. Внедрите OAuth 2.0 + JWT. Настройте wp-config.php (если часть на WordPress) для работы с внешним токеном: define('JWT_AUTH_SECRET_KEY', '...');
2. Мигрируйте данные. Используйте паттерн Strangler Fig: постепенно переводите запросы на новый сервис, оставляя старый код как fallback.
3. Настройте мониторинг. Prometheus + Grafana для метрик, Jaeger для трассировки запросов.
4. Запустите A/B-тест. Сравните время ответа и ошибки до/после.

Опыт AVOdigital: реальные кейсы

В одном из проектов мы вынесли поиск по каталогу в отдельный сервис на Elasticsearch. Монолит на PHP (WordPress + WooCommerce) не справлялся с 15 000 запросов в минуту. После миграции время поиска упало с 2,5 секунд до 200 мс. Обмен данными настроили через RabbitMQ: при изменении товара в админке публиковалось событие product.updated, сервис поиска обновлял индекс. Аутентификация — JWT, проверка через Nginx auth_request.

Другой кейс — интернет-магазин с интеграцией 1С. CommerceML-файлы приходили каждые 5 минут, монолит «зависал» на время обработки. Мы выделили сервис-импортёр на Go, который парсил XML, валидировал и складывал в Redis, а затем через RabbitMQ уведомлял каталог. Время простоя упало до нуля.

Частые вопросы