Alauda Service Mesh
  • Русский

    • Основные понятия

    Содержание

    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), отправляя конфигурации и инструкции для управления трафиком сервисов, обеспечения безопасности и сбора и обработки телеметрии. Это позволяет администраторам и разработчикам централизованно управлять всей service mesh с гибкой конфигурацией.

    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: позволяют генерировать телеметрию с помощью API OpenTelemetry на конкретных языках.
    • Instrumentation Libraries: автоматически или вручную инструментируют приложения для сбора телеметрии.

    OpenTelemetry поддерживает несколько языков и сторонние реестры, предоставляя данные наблюдаемости для JVM и middleware. Он определяет отраслевые стандарты спецификаций данных, облегчая лучшую интеграцию с различными open-source инструментами наблюдаемости.

    Техническое сравнение Istio и OpenTelemetry

    Функция/ВозможностьIstioOpenTelemetry
    Поддержка протоколовПоддерживает протоколы 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-ссылок, внутренние цепочки вызовов методов и связи сервисов с 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 — отличный выбор.

    Каждая технология имеет свои уникальные преимущества и области применения. Выбор должен основываться на конкретных бизнес-требованиях, технологическом стеке и учёте будущей масштабируемости и интеграции. В некоторых случаях их можно использовать совместно для достижения комплексных решений по управлению сервисами и наблюдаемости.