Service Mesh: невидимая инфраструктура надёжности

Представьте оживлённый перекрёсток в час пик. Машины (микросервисы) едут в разные стороны, подрезают друг друга, кто-то пытается повернуть налево, кто-то стоит в пробке. Без светофоров и регулировщика тут будет коллапс. Service mesh — это тот самый регулировщик, только для микросервисов. Он не участвует в движении сам, но управляет им: пропускает, тормозит, блокирует, страхует.

Что такое service mesh?

Service mesh — это выделенный инфраструктурный слой, который берёт на себя всю коммуникацию между микросервисами. Выглядит это так: рядом с каждым вашим сервисом запускается крошечная программа-посредник — sidecar proxy. Все входящие и исходящие запросы проходят через него. А управляет всей этой армией прокси control plane — мозг, который раздаёт команды.

Вот как это делится:

  • Data plane (плоскость данных): сами sidecar-прокси. Они перехватывают трафик, применяют правила, собирают статистику. Каждый микросервис теперь общается не напрямую с соседом, а через свой прокси.
  • Control plane (плоскость управления): центральный сервис, который говорит прокси, что делать. Выпустили новую версию? Control plane скажет прокси: «направляй 10% трафика на новую версию, 90% — на старую».

Технически это выглядит незаметно для разработчика. Код сервиса не меняется — он просто шлёт запросы localhost'у (своему sidecar), а тот уже разбирается с внешним миром. Service mesh становится прозрачным слоем инфраструктуры.

Что даёт service mesh для надёжности

Ретраи, таймауты, circuit breaker «из коробки»

Вспомните главу про техники надёжности: когда сервис А зовёт сервис Б, нужно ставить таймауты, делать повторные попытки с экспоненциальной задержкой, а если Б совсем лёг — размыкать цепь circuit breaker-ом.

Без service mesh каждый разработчик должен вручную добавить эти паттерны в код каждого сервиса. А когда сервисов тридцать или пятьдесят — гарантированно где-то забудут, где-то сделают неправильно.

Service mesh даёт это автоматически, на уровне инфраструктуры. Вы просто говорите control plane: «все вызовы к payment-service повторяй до трёх раз с таймаутом 2 секунды». Sidecar сам выполнит retry, зафиксирует timeout и разомкнёт цепь, если payment-service упал. Код остаётся чистым.

Управление трафиком (canary, traffic splitting)

Это одна из самых полезных фич для тех, кто боится сломать прод. Вы выкатили новую версию сервиса, но не уверены в ней на 100%. С service mesh можно:

  • направить на новую версию 1% реальных запросов (канарейка). Если она упадёт — пострадает всего 1% пользователей.
  • потом аккуратно поднять до 10%, до 50%, и только убедившись — переключить 100%.
  • или сделать mirroring (зеркалирование трафика): копировать запросы на новую версию, но не показывать результат пользователю. Так можно проверить, выдержит ли новинка нагрузку, без риска для клиентов.

И всё это не требует менять код, балансировщики или DNS. Control plane просто меняет правила для прокси.

Fault injection (внедрение ошибок) для chaos engineering

Хотите проверить, как система переживёт отказ? Service mesh позволяет вставить ошибку: сказать прокси «на 5% запросов отвечай 500-й ошибкой» или «добавь задержку в 300 миллисекунд на запросы к xyz-service». Это идеальный инструмент для chaos engineering — вы проверяете resilience системы, не трогая реальные серверы.

mTLS и безопасность: шифрование между сервисами

Когда два сервиса общаются внутри инфраструктуры, возникает соблазн не шифровать трафик — «это же внутренняя сеть». Но в современном мире, особенно после главы про DevSecOps, мы знаем: доверять нельзя никому и никогда.

Service mesh автоматически включает mutual TLS (mTLS) — двустороннее шифрование каждого межсервисного вызова. Каждый sidecar получает сертификат от control plane, проверяет, что сосед — это действительно тот, за кого себя выдаёт, и шифрует канал. Разработчик об этом даже не знает — он просто делает HTTP-вызов к localhost, а sidecar сам заворачивает его в шифрование.

Это решает две проблемы разом: защита данных при перехвате (кто-то прослушивает внутреннюю сеть) и защита от подделки (злоумышленник запустил свой сервис и притворяется легитимным).

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

В главе про телеметрию мы разобрали три столпа: метрики, логи, трейсы. Service mesh даёт их автоматически, без добавления кода в каждый сервис.

Каждый sidecar прокси знает:

  • Сколько запросов прошло через него (латентность, ошибки, трафик — прям те самые золотые сигналы).
  • Какой сервис звонил, какой отвечал, сколько длился вызов (distributed tracing).
  • Какие ошибки вернулись, какие повторы сработали.

В результате вы получаете дашборд, где видно золотые сигналы по каждому сервису в отдельности, а трейсы обогащены метаданными от service mesh (например, время в очереди прокси). И всё это — без единой строчки кода в ваших микросервисах.

Когда service mesh нужен, а когда — лишняя сложность

Service mesh — не серебряная пуля. У него есть своя цена:

Ставьте service mesh, если:

  • У вас больше 10–15 микросервисов и они активно общаются друг с другом.
  • Вы делаете несколько деплоев в день и нуждаетесь в canary-развёртываниях.
  • Вы хотите централизованно управлять retry, таймаутами и шифрованием.
  • У вас есть команда, которая может его администрировать (это очень важно).

Не ставьте service mesh, если:

  • У вас 3–5 микросервисов или монолит. Сложность service mesh перевесит выгоду.
  • У вас нет выделенной инфраструктурной команды. Service mesh — это операционная нагрузка.
  • У вас очень низкие требования к latency (микросекунды). Каждый sidecar добавляет 1–5 миллисекунд задержки на вызов.

Важно

Service mesh это инструмент для зрелых платформ. Если вы ещё не наладили базовый мониторинг, не автоматизировали деплой и не понимаете своих SLO - service mesh вас не спасёт. Он усилит то, что уже работает. Но не починит то, что сломано.

Аналогия: service mesh — это система конвейеров на заводе. Если у вас две ручные тележки — конвейер излишен. Если у вас огромный цех с сотнями станков — без конвейера вы утонете в логистике.

Примеры: кто делает service mesh

На рынке есть несколько зрелых проектов, но не стоит сейчас лезть в их сравнение:

  • Istio — самый популярный, богатый функционалом, но тяжёлый (со своим привкусом сложности).
  • Linkerd — легче, проще (CNCF проект, ставится за пару команд).
  • Consul (HashiCorp) — хорош, если вы уже в экосистеме HashiCorp (Terraform, Vault, Nomad).

Выбор между ними — это компромисс между функциональностью и простотой. Но для неинженерного понимания важно другое: все они делают одно и то же — убирают инфраструктурную сложность из кода и переносят её на уровень платформы.

Service mesh не делает ваш код надёжнее магически. Он даёт вам готовые, проверенные инструменты, чтобы вы не писали один и тот же retry и circuit breaker для каждого сервиса руками. А значит — меньше ошибок, быстрее деплой, спокойнее ночи.