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