Микросервисы

Микросервисная архитектура — это подход к бэкенд-разработке, при котором система декомпозируется на небольшие, независимо развёртываемые сервисы, каждый из которых владеет конкретной бизнес-возможностью и взаимодействует через сеть. Каждый микросервис, как правило, владеет собственной базой данных (PostgreSQL, MySQL или MongoDB) для обеспечения слабой связанности и поддержки полиглотного хранения, тогда как синхронные вызовы между сервисами используют REST поверх HTTP/2 или gRPC с Protocol Buffers для низкой задержки. Асинхронная событийно-ориентированная интеграция через Kafka или RabbitMQ ещё сильнее разделяет сервисы, позволяя чисто применять паттерны CQRS, Saga и ограниченные контексты DDD через границы сервисов. Операционно микросервисная архитектура требует оркестрации контейнеров с Kubernetes (kubectl, Helm charts), сервисной сетки для mTLS и управления трафиком (Istio, Linkerd), а также развитой наблюдаемости с распределённой трассировкой (Jaeger, OpenTelemetry), централизованным логированием (стек ELK) и метриками (Prometheus + Grafana). CI/CD-пайплайны на GitHub Actions или GitLab CI собирают и публикуют Docker-образы для каждого сервиса, позволяя командам деплоить отдельные микросервисы несколько раз в день без координации монолитного релиза.

Как это работает

Микросервисы имеет варианты: монолит (один деплоябл, простой ops, тяжело масштабировать команды за ~30 инженеров), modular monolith (один деплоябл, внутренние границы модулей, масштабируется намного дальше, чем считают), микросервисы (много мелких сервисов, сложный ops, масштабирует команды). Паттерны: hexagonal / clean architecture (отделить домен от инфры), CQRS (раздельные read + write модели), event sourcing (state из event log), domain-driven design (моделируем бизнес). "Правильная" архитектура — простейшая, решающая текущие ограничения.

Когда применять

Каждый новый проект — modular monolith. Разделяйте на сервисы только когда (а) в команде > ~30 инженеров, (б) у одного компонента сильно другие требования к масштабу, (в) регуляторные границы требуют изоляции. "Архитектура" — это в основном про что вы можете дёшево менять потом; принимайте решения, откладывающие необратимость (БД на сервис — очень необратимо; границы модулей в монолите — дёшево перерисовать).

Типичные ошибки

Ловушки Микросервисы: микросервисы для 5-инженерной команды (каждый сервис стоит ops + observability; больше дебажите RPC, чем шипите фичи); погоня за паттернами из FAANG-блогов на startup-масштабе (их ограничения не ваши); переписывание "ради clean architecture" без замеренной выгоды (clean ≠ better — только если окупается в изменяемости). Оптимизируйте под следующие 12 месяцев, не под 10x масштаб, которого нет.

Как это работает

Когда применять

Типичные ошибки

Связанные понятия

Полезные ресурсы