О сервисе

Сервис интеграционного взаимодействия (услуга 1.9) — это интеграционная платформа нового поколения, построенная на базе open-source продукта Istio v1.11.2. Продукт отвечает за надёжную доставку запросов через сложную топологию сервисов, составляющих современное приложение, созданное для работы в облаке.
Правила маршрутизации трафика Istio позволяют легко контролировать поток трафика и вызовы API между сервисами.
Модель управления трафиком Istio основана на прокси-серверах Envoy (Компонент «Сервисный прокси Platform V Synapse Service Mesh»), которые развертываются вместе с вашими сервисами.
Весь трафик, который отправляют и получают ваши сетевые сервисы, проксируется через Envoy (Компонент «Граничный прокси Platform V Synapse Service Mesh»), что позволяет легко направлять и контролировать трафик вокруг вашей сети без внесения каких-либо изменений в сервисы.
Общая задача Сервиса интеграционного взаимодействия - возможность построения Service Mesh для обеспечения сетевых коммуникаций между сервисами с использованием прокси. Вызовы между сервисами перехватываются прокси-серверами, работа которых координируется централизованной сетевой службой, предоставляющей API для управления сетью и наблюдения за ней.
Image

Увеличить

Функциональные возможности

  • Управление трафиком:
    • автоматическая балансировка нагрузки;
    • контроль HTTP, gRPC, WebSocket и TCP-трафика через множество правил маршрутизации, повторов, аварийных переключений, лимитов запросов, внедрений неисправностей и так далее;
    • реализация различных стратегий развертывания сервисов.
  • Безопасность на границе и внутри сети микросервисов: обеспечение безопасности межсервисных коммуникаций посредством сквозной аутентификации и авторизации.
  • Наблюдаемость сети и real-time контроль: сбор метрик, логирование и трассировка запросов внутри кластера.

Архитектура сети с Istio

В архитектуре сети Service Mesh существуют следующие изолированные контуры сети:
  • внешняя (или открытая) сеть граничит с внутрисетевым пространством Service Mesh, которое является вторым сетевым контуром и содержит сущности развертки (deployment) оркестровщика сети;
  • локальная сеть внутри контейнера (например, Docker-контейнер) с бизнес-сервисом или прокси-сервером.
Image

Увеличить

Под управлением Istio происходит внедрение контейнера с proxy-сервером напротив каждого контейнера с бизнес-сервисом. Proxy-сервер перехватывает и управляет всем входящим и исходящим трафиком из контейнера с бизнес-сервисом. Istio внедряет два контейнера с proxy-сервером на границе Service Mesh и внешней сети: первый из них (ingress-шлюз) служит для контроля всего входящего трафика, а второй (egress-шлюз) — для управления всего исходящего трафика.
Администратор сети имеет возможность декларативно конфигурировать Service Mesh при помощи API Istio, который поддерживает требуемое состояние сети, транслируя необходимые конфигурации на каждый перехватывающий proxy-сервер. Так формируется требуемая сетевая логика и конфигурации безопасности в сети.
Управляющие сервисы Istio в терминологии Service Mesh называются «control plane» (на рисунке — сервис Istiod), а совокупность управляемых proxy-серверов — «data plane».
Ключевой архитектурной особенностью Service Mesh является Sidecar паттерн, то есть внедрение контейнера с proxy-сервером в атомарную группу контейнеров (такую как Pod в Kubernetes), включающую контейнер с бизнес-сервисом. Такая концепция позволяет реализовать нужную сетевую логику и обеспечить ее безопасность посредством управляющих воздействий из control plane в каждый proxy-сервер, а также получить детальную телеметрию при сборе обратной информации из data plane. Все изменения сетевой логики внутри Service Mesh являются прозрачными для бизнес-сервисов и не требуют их доработок.

Показатели назначения

Минимальная конфигурация Сервиса обеспечивает:
  • обработка повторов (типы ошибок, в случае которых применяется повтор: gateway-error, connect-failure, refused-stream, reset):
    • количество попыток повтора — 3;
    • интервал между попытками повтора — 5 секунд.
  • исключение деградирующих подов из балансировки:
    • минимальное время исключения из балансировки — 30 секунд;
    • количество ошибок, после которого под исключается из балансировки — 5;
    • максимальный процент реплик подов, который можно исключить — 10.
Предыдущий раздел
1.8 Объектное хранилище
Следующий раздел
Управление трафиком
Была ли страница полезной?