Разработка микросервисной архитектуры бэкенда мобильного приложения
Переход к микросервисам оправдан не тогда, когда «так модно», а когда монолит начинает создавать конкретные операционные проблемы: команда из 15+ разработчиков конфликтует в одной кодовой базе, релизный цикл замедлился до двух недель из-за координации между отделами, или одна «горячая» фича (стриминг, обработка платежей) требует отдельного масштабирования, а не тянуть за собой весь монолит.
Где микросервисы создают больше проблем, чем решают
Начнём с антипаттернов, потому что именно сюда уходит большинство бюджетов.
Distributed monolith. Разбили монолит на 15 сервисов, но каждый запрос мобильного клиента синхронно ждёт цепочку вызовов: API Gateway → UserService → OrderService → ProductService → PaymentService. Один сервис лагает — весь запрос висит. Это не микросервисная архитектура, это монолит через HTTP с дополнительным latency overhead. Признак: сервисы не могут работать независимо, деплой одного требует координации с другими.
Grapevine data consistency. OrderService синхронно вызывает InventoryService, получает 200 OK, но между проверкой остатка и списанием другой запрос успел занять последний товар. Race condition на уровне распределённой системы. Решение — Saga pattern: либо choreography (события через Kafka/RabbitMQ), либо orchestration (Temporal, Apache Camel).
Overhead на маленьких командах. Три разработчика, пять сервисов — каждый деплой требует обновления пяти Docker-образов, пяти Helm-чартов, пяти наборов переменных окружения. Velocity падает, ошибки конфигурации растут. Для команды до 8 человек модульный монолит (Modular Monolith) или monolith-first с последующей декомпозицией — честнее.
Как строим микросервисную архитектуру для мобильного приложения
Декомпозиция по доменам (Domain-Driven Design)
Bounded Context — основной принцип: каждый сервис владеет своими данными и не читает чужую БД напрямую. Типичная декомпозиция для e-commerce мобильного приложения:
| Сервис | Ответственность | БД |
|---|---|---|
| user-service | Регистрация, профиль, аутентификация | PostgreSQL |
| catalog-service | Товары, категории, поиск | PostgreSQL + Elasticsearch |
| order-service | Заказы, статусы, история | PostgreSQL |
| payment-service | Платёжные методы, транзакции | PostgreSQL |
| notification-service | Push, email, SMS | Redis + PostgreSQL |
| media-service | Загрузка и обработка медиа | S3 + PostgreSQL |
API Gateway — единая точка входа для мобильного клиента
Мобильный клиент никогда не знает о топологии сервисов. Один хост, один TLS-сертификат. Gateway берёт на себя: аутентификацию JWT (не дублируем в каждом сервисе), rate limiting, роутинг по версиям API, трансформацию запросов.
Технологии: Kong (production-proven, плагины для auth/rate limit/logging), AWS API Gateway если инфраструктура в AWS, Traefik для Kubernetes-native решения. Для команд, которые хотят кастомную логику — custom Gateway на Go (BFF — Backend for Frontend), особенно если мобильный клиент нуждается в агрегации данных из нескольких сервисов в один ответ.
Асинхронная коммуникация
Синхронные вызовы между сервисами — только там, где результат нужен немедленно (проверка лимита перед платежом). Всё остальное — через message broker.
Apache Kafka для высоконагруженных сценариев: event sourcing, аудит-лог, стриминг метрик. Топик order.created — подписаны notification-service (отправит push), analytics-service (обновит метрики), loyalty-service (начислит баллы). Каждый независимо, без coupling.
RabbitMQ для task queue: транскодирование видео, генерация PDF, отправка email. Проще в операционном плане, достаточно для большинства мобильных приложений.
Кейс: платформа для стриминга фитнес-контента, 200 000 MAU. Исходный монолит на Node.js начал давать timeout на /api/workouts/start — там синхронно вызывались: запись в лог, обновление прогресса, инкремент счётчика просмотров, проверка ачивок. Декомпозиция: workout-service публикует событие workout.started в Kafka, остальные сервисы обрабатывают асинхронно. Latency endpoint: с 800ms до 40ms.
Service Mesh и observability
В микросервисной среде без observability вы слепы. Обязательный минимум:
- Distributed tracing — Jaeger или Zipkin с OpenTelemetry SDK в каждом сервисе. Когда мобильный клиент жалуется на медленный ответ, trace показывает какой именно сервис виноват
-
Centralized logging — ELK Stack (Elasticsearch + Logstash + Kibana) или Loki + Grafana. Correlation ID пробрасывается через все сервисы в заголовках (
X-Trace-ID) - Service mesh — Istio или Linkerd для mTLS между сервисами, circuit breaker, retry, timeout на уровне инфраструктуры, без кода
Circuit Breaker для защиты мобильного клиента
Если payment-service деградирует, order-service должен быстро вернуть fallback, а не ждать таймаута 30 секунд. Resilience4j (Java), Polly (.NET), go-circuitbreaker — circuit breaker размыкается после N последовательных ошибок, быстро возвращает 503, через 30 секунд пробует снова. Мобильный клиент получает ответ за 100ms, а не таймаут.
Процесс внедрения
Миграция монолита в микросервисы — не «переписываем всё разом». Паттерн Strangler Fig: новый функционал — отдельный сервис, старый — постепенно вырезается из монолита. Начинаем с наименее связанных доменов (обычно уведомления, медиа, аналитика).
Сроки: Проектирование архитектуры + базовая инфраструктура (Gateway, брокер, мониторинг) — 4–6 недель. Полная декомпозиция продуктового монолита в 5–8 сервисов с CI/CD — 16–24 недели.