Основные понятия
Содержание
Service Mesh
Service Mesh — это независимый и настраиваемый инфраструктурный слой, добавляемый к приложению. Он используется для управления и контроля коммуникации между микросервисными приложениями, предоставляя возможности управления трафиком сервисов, мониторинга сервисов, контроля безопасности доступа к сервисам и выпуска сервисов.
В традиционной микросервисной архитектуре коммуникация между сервисами обычно обрабатывается напрямую в коде приложения, что увеличивает сложность и связанность. Service Mesh внедряет лёгкий прокси (Envoy, развернутый как sidecar-контейнер в каждом поде сервиса) для управления и контроля межсервисного взаимодействия. Эти прокси отделены от кода приложения и выполняют задачи маршрутизации запросов, балансировки нагрузки, восстановления после сбоев, управления трафиком и аутентификации безопасности, позволяя разработчикам сосредоточиться на бизнес-логике без необходимости заботиться о базовых механизмах и функциональностях коммуникации.
Внедрение Service Mesh позволяет разработчикам лучше управлять и контролировать коммуникацию между микросервисными приложениями и добавлять новые функции без изменения кода приложения. Service Mesh поддерживает различные инфраструктуры, такие как виртуальные машины и контейнеры, и может интегрироваться с платформами оркестрации контейнеров (например, Kubernetes), обеспечивая лучший опыт построения контейнеризованной микросервисной архитектуры в эпоху cloud-native.
Istio
Istio — это open-source сервисная сетка, которая прозрачно интегрируется в существующие распределённые приложения для обеспечения управления трафиком, применения политик, сбора телеметрии и обеспечения безопасности. Istio предлагает комплексные возможности управления сервисами для микросервисной архитектуры, поддерживает несколько языков и в основном использует Kubernetes в качестве реестра сервисов.
Istio предоставляет мощные функции для защиты, подключения и мониторинга сервисов единым и эффективным способом. С помощью Istio можно достичь балансировки нагрузки, межсервисной аутентификации и мониторинга с минимальными или без изменений в коде сервисов. Ключевые возможности включают:
- Безопасную межсервисную коммуникацию внутри кластера, включая TLS-шифрование, аутентификацию на основе идентичности и авторизацию.
- Автоматическую балансировку нагрузки для HTTP, gRPC, WebSocket и TCP трафика.
- Тонкое управление поведением трафика с помощью богатых правил маршрутизации, повторных попыток, переключения при сбоях и инъекции ошибок.
- Подключаемый слой политик и API конфигурации для контроля доступа, ограничения скорости и управления квотами.
- Автоматический сбор метрик, логов и трассировок со всего трафика внутри кластера, включая входящий и исходящий трафик.
- Масштабируемость для различных сценариев развертывания. Контрольная плоскость работает на Kubernetes, и вы можете добавлять приложения, развернутые в кластере, расширять сетку на другие кластеры и даже подключать виртуальные машины или другие конечные точки вне Kubernetes.
Архитектура Istio показана ниже.
Control Plane
Контрольная плоскость Istio отвечает за управление и конфигурирование прокси. Она взаимодействует с прокси плоскости данных (Envoy), отправляя конфигурации и инструкции для управления трафиком сервисов, обеспечения безопасности и сбора и обработки телеметрии. Это позволяет администраторам и разработчикам централизованно управлять всей сервисной сеткой с гибкой настройкой.
Data Plane
Плоскость данных Istio состоит из набора интеллектуальных прокси (Envoy), развернутых и работающих как sidecar-контейнеры в подах сервисов. Эти прокси перехватывают, обрабатывают и пересылают весь трафик между сервисами.
Плоскость данных выполняет управление трафиком, восстановление после сбоев, применение политик безопасности и другие функции, обеспечивая надёжность и безопасность межсервисной коммуникации. Также она предоставляет богатые возможности мониторинга и трассировки, помогая разработчикам понимать и отлаживать поведение коммуникации сервисов.
Envoy
Envoy используется в качестве прокси для плоскости данных Istio и является единственным компонентом Istio, взаимодействующим с трафиком плоскости данных.
Envoy развертывается и работает как sidecar в подах сервисов, обрабатывая и пересылая весь входящий и исходящий трафик сервисов в сервисной сетке, предоставляя сетевые функции и возможности управления, такие как контроль трафика, балансировка нагрузки, восстановление после сбоев и безопасность.
Sidecar
Паттерн sidecar широко используется в микросервисах и контейнеризованных приложениях для расширения функциональности и производительности приложения путём добавления вспомогательных контейнеров или прокси рядом с основным контейнером приложения.
Envoy, формирующий плоскость данных Istio, развертывается как sidecar-контейнер в подах сервисов.
Service Gateway
Сервисные шлюзы включают Egress Gateway и Ingress Gateway, работающие на границе сервисной сетки для управления трафиком, входящим и выходящим из сетки. Они позволяют задавать, какой трафик разрешён покидать или входить в сетку.
OpenTelemetry
OpenTelemetry — это open-source фреймворк наблюдаемости, направленный на генерацию, обработку и передачу телеметрических данных, включая метрики, логи и трассировки. Разработанный Cloud Native Computing Foundation (CNCF), он предоставляет набор стандартных протоколов и инструментов для отправки данных в любую систему наблюдаемости. Основные компоненты OpenTelemetry включают:
- Collector: принимает, обрабатывает и экспортирует телеметрические данные.
- Language SDKs: позволяют генерировать телеметрию с помощью API OpenTelemetry на конкретных языках.
- Instrumentation Libraries: автоматически или вручную инструментируют приложения для сбора телеметрии.
OpenTelemetry поддерживает множество языков и сторонних реестров, предоставляя данные наблюдаемости для JVM и middleware. Он определяет отраслевые стандарты спецификаций данных, облегчая интеграцию с различными open-source инструментами наблюдаемости.
Техническое сравнение Istio и OpenTelemetry
| Функция/Возможность | Istio | OpenTelemetry |
|---|---|---|
| Поддержка протоколов | Поддерживает протоколы gRPC, HTTP, TCP. | Поддерживает HTTP, TCP и различные RPC-протоколы, такие как Dubbo, Redis и др. |
| Управление сервисами | Обеспечивает балансировку нагрузки, circuit breaking, connection pool, таймауты и повторные попытки. | Не предоставляет возможностей управления сервисами. |
| Маршрутизация сервисов | Предоставляет богатые правила и стратегии маршрутизации, такие как маршрутизация по весу, маршрутизация по заголовкам запросов, зеркалирование трафика, инъекция ошибок и др. | Не поддерживает маршрутизацию. |
| Топология и цепочки вызовов | Отображает все узлы внутри сетки, включая сервисы, ingress gateways, service entries, egress gateways, исключая узлы middleware. Цепочки вызовов включают HTTP span вызовов сервисов с внедрёнными sidecar, содержащие данные, такие как URL, код статуса и др. | Отображает узлы, включая сервисы и middleware, исключая ingress и egress gateways. Цепочка вызовов включает HTTP link данные, внутренние цепочки вызовов методов и связи сервис-мидлвар. Данные span также могут активно отправляться через SDK. |
| Данные мониторинга | Предоставляет полные метрики входящего и исходящего трафика для сервисов. | Предоставляет полные метрики входящего и исходящего трафика для сервисов, а также метрики JVM. |
| Совместимость с реестрами | Поддерживает Kubernetes в качестве реестра сервисов. | Поддерживает сторонние реестры и реестр Kubernetes. |
| Пропагация Trace ID | Требует изменений в коде для реализации пропагации Trace ID. | Реализует автоматическую пропагацию Trace ID. |
| Требования к ресурсам | Может требовать больше вычислительных ресурсов, так как каждому экземпляру сервиса нужен прокси Envoy. | Требует меньше дополнительных ресурсов, не требует прокси рядом с каждым экземпляром сервиса. |
Рекомендации по выбору
- Управление сервисами: Если необходимы возможности управления сервисами, лучше выбрать Istio.
- Наблюдаемость: Если требуется мощная поддержка наблюдаемости, особенно для мониторинга JVM, более подходит OpenTelemetry.
- Ограниченные ресурсы: В условиях ограниченных ресурсов OpenTelemetry может быть более лёгким вариантом, так как не требует прокси рядом с каждым экземпляром сервиса.
- Поддержка нескольких языков и реестров: Для сценариев с поддержкой нескольких языков и использованием сторонних реестров OpenTelemetry предлагает большую гибкость.
- Безвнедренческая пропагация Trace ID: Если вы используете Java-приложение и хотите достичь безвнедренческой пропагации Trace ID для full-stack трассировки, использование OpenTelemetry Java Agent — отличный выбор.
Каждая технология имеет свои уникальные преимущества и области применения. Выбор должен основываться на конкретных бизнес-требованиях, технологическом стеке и учёте будущей масштабируемости и интеграции. В некоторых случаях их можно использовать совместно для достижения комплексных решений по управлению сервисами и наблюдаемости.