Стратегии развертывания микросервисов

b

Материалы и компоненты инфраструктуры для развертывания микросервисов

Базовым элементом любой стратегии является контейнеризация на уровне ядра ОС с использованием Docker (версии 24.0+). Для оркестрации контейнеров применяется Kubernetes (v1.28+) с поддержкой CRD для продвинутых сценариев. В качестве хранилища образов — OCI-compatible реестры (Harbor, Amazon ECR).

Стратегия Rolling Update: пошаговая замена экземпляров

Метод sequential deployment, реализуемый через strategy.type: RollingUpdate в Kubernetes. Производится последовательное обновление подов с контролем Ready-пробы (livenessProbe) и readinessGates.

  1. Технические параметры: maxSurge: 25% (максимальное количество новых подов одновременно), maxUnavailable: 0 (гарантия отсутствия простоев).
  2. Отличие от альтернатив: Не требует двойного объёма ресурсов (как Blue-Green), но при отказе откат занимает время, эквивалентное progressDeadlineSeconds * replicas.
  3. Производственные стандарты: Обязательное наличие preStop hook (graceful shutdown за 30 сек). Версия может быть только immutable-тегом (SHA256 или семантическая версия).

Blue-Green Deployment: зеркальное окружение и переключение трафика

Стратегия оперирует двумя идентичными средами (Blue и Green), развёрнутыми на разных наборах подов или в отдельных namespace. Параметры реализации:

Canary Release: дозированное внедрение под нагрузкой

Метод подразумевает отправку нового трафика заданной доле пользователей с контролем метрик на уровне P99 latency и error rate.

  1. Техническая реализация: Service Mesh (Istio 1.22+) или Ingress Canary. Доля трафика задаётся в весе (weight: 5 → weight: 10 → weight: 50 → weight: 100).
  2. Параметры: Минимальный порог ошибок — 0.1% (HTTP 5xx). Если error_rate > 0.5% — автоматический откат через Prometheus Alertmanager.
  3. Отличие от Rolling: Canary требует сегментирования пользователей по HTTP-заголовкам (например, X-Canary-ID) и распределённой трассировки (OpenTelemetry).

A/B Testing и Feature Toggle: стратегия на основе конфигурации

Не заменяет deployment, но дополняет его. Реализуется через feature flags-сервис (LaunchDarkly или самописный на Redis). Флаги — JSON-документы с условиями (регион, версия клиента).

Стандарты и метрики контроля качества при развертывании

Критерии для production (SLA 99.99%):

МетрикаЗначение
MTTR (среднее время восстановления)< 5 мин
Коэффициент неудачных развертываний< 2%
DORA метрики: частота деплоя≥ 1 раз/день

Технические ограничения:

  1. Размер образа: ≤ 1.5 ГБ (сумма всех слоёв). Запрещены слои с кэшами менеджеров пакетов.
  2. Тестирование: обязательное прохождение smoke-tests (5 запросов к healthcheck, статус 200) и integration-tests (Postman Collection, 100% coverage базовых кейсов).
  3. Безопасность: сканирование образа через Trivy (версия 0.55+) с блокировкой при наличии уязвимостей HIGH.

Производственные отличия от монолитной архитектуры

Для микросервисов каждая стратегия требует независимых пайплайнов CI/CD (GitHub Actions, GitLab CI — параллельные джобы для 50+ микросервисов). В монолите — один пайплайн и одно развертывание. Для микросервисов стандарт — декомпозированный деплой с версионированием по каждому апи-эндпоинту.

Добавлено: 07.05.2026