Microservices with Service Mesh

Зачем нужно знать

Service mesh становится важным, когда микросервисов уже достаточно много, чтобы сетевое поведение нельзя было держать в головах команд и в разрозненных библиотеках. Каждый сервис должен уметь шифровать service-to-service трафик, проверять identity, делать retries с timeout, открывать circuit breaker, отдавать metrics/traces и участвовать в canary. Если все это реализуется в приложениях, появляются разные версии библиотек, разные semantics retry, разные языковые ограничения и зоны, где policy просто забыли подключить.

Mesh выносит сетевые cross-cutting concerns в data plane и control plane. Приложение продолжает говорить HTTP/gRPC, а sidecar или eBPF слой берет на себя mTLS, routing, telemetry и защитные политики. Цена тоже существенная: новые CRD, новые failure modes, extra latency, память на sidecar, сложный debug. Поэтому главный навык не «поставить Istio», а понять, когда mesh окупает операционную сложность. Связанные темы: service-mesh, zero-trust-architecture, api-gateway, circuit-breaker, load-balancing, distributed-tracing.

Mental model

Service mesh можно представить как корпоративную сеть с пропускными пунктами у каждого кабинета. Люди внутри продолжают делать свою работу, но каждый вход и выход проходит через контролируемый пост: кто идет, куда, с каким сертификатом, по какому маршруту, с какими лимитами. Control plane рассылает правила, data plane применяет их на каждом hop.

В Istio data plane обычно представлен Envoy sidecar рядом с каждым app container. Istiod читает Kubernetes Services, Endpoints, VirtualService, DestinationRule, PeerAuthentication и AuthorizationPolicy, затем через xDS передает Envoy listeners, routes, clusters, endpoints и secrets. В Cilium eBPF mesh часть функций переносится ближе к kernel/node agent, уменьшая per-pod overhead, но меняя набор возможностей и способ отладки.

Что показывает диаграмма

Диаграмма microservices-mesh показывает API Gateway, control plane, config store и четыре доменных сервиса: User, Order, Payment, Notification. У каждого сервиса есть app-процесс и Envoy sidecar, а у каждого домена своя база или очередь: User PostgreSQL, Order MongoDB, Payment PostgreSQL, Notification Redis. Внешний запрос входит через gateway, дальше все межсервисные вызовы идут sidecar-to-sidecar по mTLS. Control plane связан со всеми sidecar через xDS config.

Важная деталь: приложение не обращается напрямую к чужому приложению. Gateway app идет в gateway sidecar, тот маршрутизирует в user/order sidecar, sidecar передает inbound в локальное приложение. Order app вызывает payment через свой sidecar, payment sidecar передает в payment app. Это демонстрирует ключевой принцип mesh: proxy находится на каждом hop, поэтому политика применима равномерно, независимо от языка сервиса.

Сценарии и что они учат

create-order показывает happy path заказа: gateway принимает POST, mesh отправляет auth в User Service, затем создает Order, вызывает Payment и Notification. Урок: mesh не заменяет доменную оркестрацию. Он обеспечивает безопасный и наблюдаемый транспорт между шагами. ADR-вывод: бизнес-транзакции остаются в приложениях, а mesh отвечает за route, identity, timeout, retry и telemetry.

health-check показывает control plane и sidecars как отдельный слой состояния. Sidecars отчитываются о health и получают конфигурацию. Урок: mesh добавляет собственную control-plane зависимость. Если Istiod недоступен, существующие sidecars обычно продолжают работать на последнем config, но новые изменения, cert rotation и новые pods могут пострадать. ADR-вывод: control plane должен иметь HA, monitoring и понятный upgrade path.

circuit-breaker показывает отказ Payment DB. Payment API возвращает 503, sidecar считает ошибки и открывает circuit breaker, после чего Order Service получает fallback без повторного удара по payment. Урок: circuit breaker в mesh защищает downstream даже если приложение не реализовало свою библиотеку устойчивости. ADR-вывод: mesh-level CB полезен как общий guardrail, но доменное решение о статусе payment_pending все равно принимает Order app.

Из fallback-материала service-mesh-deep стоит добавить сценарии, которые диаграмма не полностью раскрывает: xDS hot reload, AuthorizationPolicy deny, STRICT/PERMISSIVE mTLS migration, canary 95/5 и сравнение sidecar с Cilium eBPF. Они помогают читать эту demo не как статичную картинку, а как основу production-паттерна.

Trade-offs

Первый trade-off: service mesh против in-process libraries. Mesh дает единый policy plane, language-agnostic mTLS, централизованные canary и observability. Library дешевле по latency и памяти, проще в profiler, но требует поддерживать одинаковую семантику в Go, Node, Python и других языках. ADR-решение: для малого числа сервисов и одного языка часто лучше библиотека; для десятков сервисов, compliance и нескольких стеков mesh становится оправданным.

Второй trade-off: sidecar против sidecar-less/eBPF. Envoy sidecar зрелый и функциональный: L7 routing, filters, WASM, подробные логи. Но он добавляет RAM/CPU на pod и 1-3 ms на hop. Cilium eBPF снижает overhead и ускоряет startup, но L7-функции могут быть ограничены или требовать node-level Envoy, а debug уходит в kernel/agent слой. ADR-решение: выбирать не по моде, а по нужным L7 policy, latency budget и навыкам platform-команды.

Третий trade-off: STRICT mTLS против миграции. STRICT режим улучшает zero-trust, но ломает legacy clients без sidecar. PERMISSIVE режим мягче и подходит для перехода, но оставляет окно plain HTTP. ADR-подход: observability first, затем PERMISSIVE, затем namespace-by-namespace STRICT с explicit AuthorizationPolicy.

Четвертый trade-off: мощные CRD против операционного риска. VirtualService и DestinationRule дают canary, retry, timeout, outlier detection, но один неверный route может затронуть весь namespace. Нужны review, policy linting, staged rollout и dashboards.

Реальные системы

Istio является самым функциональным вариантом на Envoy: xDS, mTLS, traffic management, AuthorizationPolicy, Gateway, multi-cluster, ambient mode. Linkerd проще и легче, часто подходит командам, которым нужны mTLS и telemetry без всей ширины Istio. Cilium Service Mesh использует eBPF и node-level агенты, уменьшая per-pod overhead. Consul Connect удобен в hybrid VM/Kubernetes окружениях. AWS App Mesh предоставляет managed Envoy-интеграцию для AWS-стека.

Production-примеры обычно начинаются не с «включили все». Сначала observability, затем mTLS, затем policies, затем advanced traffic management. Lyft исторически создал Envoy как data plane, Airbnb и Adobe использовали Istio в крупных Kubernetes-средах, PayPal публично рассказывал о Linkerd для compliance-сценариев.

Anti-patterns и типичные ошибки

Mesh для пяти сервисов часто дороже, чем полезен. Включить STRICT mTLS, complex AuthorizationPolicy, retries и WASM-фильтры одним релизом означает получить трудноотлаживаемую сеть вместо надежности. Еще одна ошибка: не учитывать sidecar memory limits. При тысячах pod'ов 50-100 MB на proxy превращаются в сотни GB RAM. Опасно также настраивать retries без deadlines: mesh может усилить нагрузку на больной downstream.

Частая архитектурная ошибка: думать, что mesh автоматически исправляет плохие сервисные границы. Если Order синхронно вызывает десять сервисов в hot path, mesh лишь сделает это наблюдаемым и зашифрованным. Он не отменяет необходимости в саге, очередях, идемпотентности и нормальном data ownership.

Когда НЕ использовать

Не используйте mesh, если у вас один язык, меньше десяти сервисов и нет требований к zero-trust/compliance. Не используйте mesh как замену API Gateway для внешних клиентов: ingress, auth для public API и product-level rate limits часто остаются отдельным слоем. Не ставьте mesh в latency budget меньше 1 ms без измерений. Не начинайте с multi-cluster mesh, если single-cluster deployment и ownership еще не стабилизированы.

Также mesh не нужен для batch-only систем, где нет постоянного service-to-service трафика, или для legacy окружения, где команда не готова владеть control plane. В таких случаях лучше начать с OpenTelemetry, явных timeout/retry библиотек и mTLS на ingress/egress.

Дальше читать

В CloudArch откройте service-mesh, microservices-mesh, zero-trust-architecture, api-gateway, circuit-breaker, timeout-deadline, load-balancing, distributed-tracing, multi-region-app. Для глубокого изучения: Istio architecture, Envoy xDS API, Istio AuthorizationPolicy и PeerAuthentication, Cilium Service Mesh/eBPF материалы, Linkerd docs, книга Istio in Action, а также практики progressive delivery через VirtualService и DestinationRule.