Перейти к основному содержимому

Service Mesh

Service Mesh — архитектурный слой, управляющий сетевым взаимодействием между сервисами в распределённых системах. Каждый сервис взаимодействует с другими через прокси (sidecar), который обрабатывает весь трафик между сервисами.

Применение: часто используется в облачных инфраструктурах, контейнерах и Kubernetes.

Основные задачи​

  • Шифрование трафика между сервисами и управление доступом на уровне соединений.
  • Сбор метрик, логов и трассировок для мониторинга взаимодействий между сервисами.
  • Балансировка нагрузки, маршрутизация запросов и отказоустойчивость на уровне сетевых вызовов.
  • Автоматическое переключение при сбоях и лимитирование запросов.

Распространённые решения: Istio, Envoy Proxy, Linkerd2, Conduit, Consul Connect.

Компоненты Service Mesh​

Data Plane​

  • Набор прокси-серверов (например, Envoy), развернутых рядом с каждым сервисом (sidecar pattern).
  • Отвечает за обработку сетевого трафика между сервисами.
  • Прокси выполняют маршрутизацию, шифрование, балансировку нагрузки и сбор метрик.

Control Plane​

  • Управляет настройками Data Plane, определяет правила маршрутизации, политику безопасности и другие конфигурации.
  • Централизованно контролирует и управляет прокси в Data Plane.
  • Примеры: Istio, Consul Connect.

Плюсы​

  • Централизованное управление политиками безопасности (аутентификация, авторизация, шифрование трафика).
    Пример: Istio для настройки политики безопасности между микросервисами.

  • Встроенные инструменты для мониторинга, сбора метрик и трассировки запросов.
    Пример: Linkerd2 включает инструменты, такие как Linkerd Dashboard, для анализа метрик в реальном времени.

  • Упрощение сложных сценариев маршрутизации и балансировки нагрузки.
    Пример: Istio поддерживает канареечные релизы и A/B тестирование через сложные правила маршрутизации.

  • Удобство управления версиями сервисов и конфигурациями.
    Пример: Consul Connect поддерживает версионирование и управление конфигурациями через тегирование сервисов.

Минусы​

  • Требует сложной настройки и управления дополнительными компонентами, что усложняет инфраструктуру.

  • Введение прокси-сервисов в Data Plane может добавить накладные расходы на обработку трафика.
    Пример: Envoy Proxy может добавить задержки в обработке запросов.

  • Увеличивает потребление вычислительных ресурсов для работы прокси и Control Plane.
    Пример: развертывание Linkerd2 на большом кластере увеличивает нагрузку на инфраструктуру.

  • Интеграция с существующими системами и приложениями может быть сложной, особенно если они не были изначально спроектированы для использования Service Mesh.

Подборка материалов по теме Service Mesh​

  1. Что такое service mesh простыми словами
  2. Service Mesh: что нужно знать каждому Software Engineer
  3. 5 самых популярных вопросов при внедрении Service Mesh
  4. Istio Service Mesh: как упростить управление микросервисами
  5. Введение в Service Mesh: основные функции и преимущества
  6. Большой обзор Service Mesh: часть первая | часть вторая
  7. Использование Service Mesh для улучшения коммуникации между микросервисами
  8. Service Mesh Architecture with Istio
  9. Как работает Service Mesh и API-шлюзы в микросервисной архитектуре
  10. Авито: Поддержка mTLS в своём Service Mesh

Видео​

  1. Service mesh. Знакомство с Istio и Envoy
  2. Istio Service Mesh в федеративных топологиях Kubernetes
  3. Service Mesh для микросервисов на примере Istio
  4. Вам не нужен Service Mesh, но это не точно

Конференции​

  1. Istio в разрезе: что умеет и не умеет самый популярный Service Mesh
  2. Service Mesh для 418-х