senior

Что такое Service Mesh?

Service Mesh — это инфраструктурный слой, управляющий межсервисным взаимодействием через sidecar-прокси, развёрнутые рядом с каждым сервисом. Он берёт на себя сетевые задачи (mTLS, retry, трассировка) без изменения кода приложения.

Пример

┌─── Data Plane ──────────────────────────────────────────┐
│                                                         │
│  ┌──────┐ ┌───────┐       ┌──────┐ ┌───────┐          │
│  │ App A│─│Proxy A│──────►│Proxy B│─│ App B │          │
│  └──────┘ └───┬───┘       └───┬───┘ └──────┘          │
│               │               │                        │
└───────────────┼───────────────┼────────────────────────┘
                │               │
┌─── Control Plane ─────────────┼───────────────────────┐
│  ┌────────────▼───────────────▼──────────────┐        │
│  │ Istio Control Plane (istiod)              │        │
│  │ - Маршрутизация   - mTLS-сертификаты      │        │
│  │ - Политики        - Конфигурация прокси   │        │
│  └───────────────────────────────────────────┘        │
└───────────────────────────────────────────────────────┘

Что предоставляет Service Mesh

Наблюдаемость (Observability) — метрики, трассировка, логирование автоматически, без изменения кода.
Безопасность — mTLS между всеми сервисами, RBAC-политики.
Управление трафиком — canary deployments, A/B тестирование, fault injection.
Отказоустойчивость — retry, timeout, circuit breaker на уровне прокси.

Популярные решения

Решение	Характеристика
Istio	Наиболее функциональный, на основе Envoy. Стандарт де-факто
Linkerd	Легковесный, проще в эксплуатации
Consul Connect	От HashiCorp, интегрирован с Consul

Пример Istio: canary deployment и fault injection

# Направить 90% трафика на v1 и 10% на v2
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: payment-service
spec:
  hosts:
    - payment-service
  http:
    - route:
        - destination:
            host: payment-service
            subset: v1
          weight: 90
        - destination:
            host: payment-service
            subset: v2
          weight: 10
---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: payment-service
spec:
  host: payment-service
  subsets:
    - name: v1
      labels:
        version: v1
    - name: v2
      labels:
        version: v2

# Fault injection для тестирования устойчивости
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: customer-service
spec:
  hosts:
    - customer-service
  http:
    - fault:
        delay:
          percentage:
            value: 10  # 10% запросов получат задержку
          fixedDelay: 5s
        abort:
          percentage:
            value: 5   # 5% запросов получат ошибку 500
          httpStatus: 500
      route:
        - destination:
            host: customer-service

Когда нужен Service Mesh

Много микросервисов (50+) — ручное управление сетевыми политиками невозможно.
Строгие требования к безопасности (mTLS везде).
Нужна единообразная наблюдаемость без изменения кода сервисов.

Когда НЕ нужен

Мало сервисов (менее 10-15).
Нет Kubernetes.
Команда не готова к дополнительной операционной сложности.

На собеседовании: объясните архитектуру: Data Plane (sidecar-прокси) + Control Plane (управление). Ключевое преимущество: разработчик пишет только бизнес-логику, всё сетевое (mTLS, retry, трассировка) обеспечивается mesh’ем. Частая ошибка — предлагать Service Mesh для 5 сервисов.

#microservices