Архитектура микросервисов: проектирование, коммуникация и развёртывание

Что такое микросервисы?

Микросервисы — это архитектурный подход, который разбивает одно большое приложение (монолит) на небольшие, независимые, развёртываемые сервисы.

Каждый сервис реализует конкретную бизнес-возможность. User service, order service, payment service и т.д.

Независимое развёртывание: каждый сервис может быть развёрнут независимо. Изменения в одном сервисе не влияют на другие.

Технологическое разнообразие: каждый сервис может использовать разный технологический стек. Node.js, Python, Go, Java могут работать вместе в одной системе.

Межсервисная коммуникация

Синхронная: прямая коммуникация через REST API или gRPC. Просто, но создаёт связанность (зависимость).

Асинхронная: событийно-ориентированная коммуникация через message queue (RabbitMQ, Kafka, SQS). Обеспечивает слабую связанность.

API Gateway: единая точка входа для всех сервисов. Выполняет маршрутизацию, аутентификацию, rate limiting, load balancing.

Service mesh: инфраструктурный слой, управляющий межсервисной коммуникацией. Инструменты, такие как Istio, Linkerd, обеспечивают traffic management, observability, security.

Circuit breaker: предотвращает cascade failure при сбоях сервисов. Реализуется с помощью Hystrix или resilience4j.

Управление данными

База данных на сервис: каждый сервис имеет свою базу данных. Это сохраняет независимость сервиса.

Event sourcing: храните изменения состояния как события. Состояние может быть восстановлено из event store.

CQRS (Command Query Responsibility Segregation): разделяйте операции чтения и записи. Используйте разные модели данных и оптимизации.

Паттерн Saga: управляйте распределёнными транзакциями. Через choreography (на основе событий) или orchestration (центральный координатор).

Согласованность данных: принимайте eventual consistency. Eventual consistency практичнее strong consistency в микросервисах.

Развёртывание и масштабирование

Контейнеризация: упакуйте каждый сервис как Docker-контейнер. Оркестрируйте с помощью Kubernetes.

Auto-scaling: автоматическое масштабирование на основе нагрузки сервиса. Используйте Kubernetes HPA (Horizontal Pod Autoscaler).

Service discovery: сервисы находят друг друга динамически. Используйте Consul, Eureka или Kubernetes DNS.

Load balancing: распределяйте нагрузку между экземплярами сервиса. Алгоритмы round-robin, least connections или consistent hashing.

Blue-green deployment: deploy без простоев. Запустите новую версию в параллельном окружении, переключите трафик.

Мониторинг и наблюдаемость

Distributed tracing: отслеживайте запросы через сервисы. Используйте Jaeger, Zipkin или OpenTelemetry.

Централизованное логирование: собирайте все логи сервисов в центральном месте (ELK Stack, Loki). Отслеживайте запросы с помощью Correlation ID.

Метрики: собирайте метрики сервисов (Prometheus) и визуализируйте (Grafana). Мониторьте latency, error rate, throughput.

Health checks: каждый сервис должен предоставлять health endpoint (/health). Интегрируйте с liveness и readiness probes Kubernetes.

Alerting: определяйте правила alert для критических метрик. Управляйте on-call с помощью PagerDuty или Opsgenie.

Антипаттерны микросервисов

Распределённый монолит: сервисы тесно связаны (tight coupling). Изменения сложны. Независимое развёртывание невозможно.

Общая база данных: все сервисы используют одну базу данных. Это устраняет независимость сервиса.

Chatty-сервисы: слишком много сетевых вызовов между сервисами. Латентность растёт, производительность падает.

Нано-сервисы: сервисы слишком малы. Overhead (сеть, сериализация) превышает пользу.

Преждевременная оптимизация: переход к микросервисам без начала с монолита. Начинайте с монолита, разбивайте при необходимости.