1 В избранное 0 Ответвления 0

OSCHINA-MIRROR/knative-docs

Клонировать/Скачать
README.md 12 КБ
Копировать Редактировать Web IDE Исходные данные Просмотреть построчно История
Отправлено 27.05.2025 06:04 d330922

Knative Eventing — это система, предназначенная для решения распространенной потребности в облачной native разработке и предоставляющая составные примитивы для обеспечения позднего связывания источников событий и потребителей событий.

Функциональность

Knative Eventing поддерживает несколько режимов использования. Следующие сценарии хорошо поддерживаются существующими компонентами; поскольку система модульная, возможно также комбинировать компоненты новыми способами.

  1. Я хочу только публиковать события, мне не важно, кто их потребляет. Отправьте события в Broker как HTTP POST. SinkBinding может быть полезен для декомпозиции конфигурации назначения от вашего приложения.

  2. Я хочу только потреблять события типа X, мне не важно, как они публикуются. Используйте Trigger для потребления событий из Broker на основе атрибутов CloudEvents. Ваше приложение будет получать события как HTTP POST.

  3. Я хочу трансформировать события через серию шагов. Используйте Channels и Subscriptions для определения сложных топологий передачи сообщений. Для простых потоков обработки Sequence автоматизирует построение Channels и Subscriptions между каждым этапом.

Knative также поддерживает некоторые дополнительные шаблоны, такие как Параллельное распределение событий и маршрутизацию ответных событий как из Channels, так и из Brokers.## Обзор дизайна

Knative Eventing спроектирован с учетом следующих целей:

  1. Услуги Knative Eventing слабо связаны. Эти службы могут быть разработаны и развернуты независимо на различных платформах (например, Kubernetes, виртуальные машины, SaaS или FaaS).
  2. Производители событий и потребители событий независимы. Любой производитель (или источник) может генерировать события до тех пор, пока активные потребители событий не начнут их прослушивать. Любые потребители событий могут выразить интерес к событию или классу событий до того, как будут созданы производители этих событий.
  3. Другие службы могут быть подключены к системе Eventing. Эти службы могут выполнять следующие функции:
    • Создание новых приложений без изменения производителя событий или потребителя событий.
    • Выбор и нацеливание на конкретные подмножества событий от их производителей.
  4. Обеспечение взаимодействия между службами. Knative Eventing соответствует спецификации CloudEvents, разработанной CNCF Serverless WG.

Потребители событий

Чтобы включить доставку в несколько типов сервисов, Knative Eventing определяет два общих интерфейса, которые могут быть реализованы нескольким ресурсам Kubernetes:1. Addressable объекты способны получать и подтверждать событие, доставленное по HTTP на адрес, определенный в поле status.address.url. В качестве специального случая, основной объект Kubernetes Service также соответствует интерфейсу Addressable.

  1. Callable объекты способны получать событие, доставленное по HTTP и преобразовывать событие, возвращая 0 или 1 новые события в HTTP-ответе. Эти возвращаемые события могут быть дальнейшим образом обработаны таким же образом, как события от внешнего источника событий.### Источники событий

Чтобы узнать о работе с источниками событий, обратитесь к документации по источникам событий.

Брокеры и триггеры событий

Объекты Брокер и Триггер делают фильтрацию событий по атрибутам событий простым.

Брокер предоставляет корзину событий, которая может быть выбрана по атрибутам. Он получает события и пересылает их подписчикам, определенным одним или несколькими соответствующими Триггерами. Поскольку Брокер реализует Addressable, отправители событий могут отправлять события в Брокер путем POST-запроса события на адрес status.address.url Брокера.

Триггер описывает фильтр по атрибутам события, который должен быть доставлен Addressable. Вы можете создать столько Триггеров, сколько необходимо.

Для большинства сценариев использования достаточно одного брокера (корзины) на namespace, но есть несколько сценариев использования, где несколько брокеров (несколько корзин) могут упростить архитектуру. Например, отдельные брокеры для событий, содержащих личную идентифицируемую информацию (PII), и событий без PII, могут упростить правила аудита и контроля доступа.

Диаграмма Брокер-Триггер

Регистр событий

Knative Eventing определяет объект EventType для упрощения обнаружения типов событий, которые могут быть получены потребителями из брокеров.Регистр состоит из коллекции типов событий. Типы событий, хранящиеся в регистре, содержат всю необходимую информацию для потребителя для создания Триггера без использования какого-либо другого вне-канального механизма. Чтобы узнать, как использовать реестр, см. документацию Event Registry.

Упрощение доставки событий

Кастомный объект SinkBinding поддерживает декомпозицию производства событий от их доставки.

При создании SinkBinding вы ссылаетесь на Addressable и Kubernetes объект, который предоставляет PodTemplateSpec. SinkBinding внедряет переменные окружения ($K_SINK для URL-адреса назначения) в PodTemplateSpec, чтобы приложение не требовало взаимодействия с API Kubernetes для поиска назначения событий.

Каналы событий и подписки

Knative Eventing также определяет слой перенаправления и сохранения событий, называемый каналом. Каждый канал является отдельным Kubernetes Custom Resource. События доставляются в сервисы или перенаправляются в другие каналы (возможно, другого типа) с помощью Подписок. Это позволяет доставлять сообщения в кластере в зависимости от требований, так что некоторые события могут обрабатываться с использованием в-памяти реализации, а другие — сохраняться с использованием Apache Kafka или NATS Streaming.См. Список реализации каналов.

Высокоуровневые конструкции событий

Существуют случаи, когда вы можете захотеть использовать набор взаимодействующих функций, и для этих случаев Knative Eventing предоставляет два дополнительных ресурса:

  1. Последовательность позволяет определить последовательный список функций.
  2. Параллельность позволяет определить список ветвей для событий.

Будущие цели дизайна

Основное внимание для следующего выпуска Eventing будет уделено упрощению реализации источников событий. Источники управляют регистрацией и доставкой событий из внешних систем с помощью Kubernetes Custom Resources. Узнайте больше о разработке Eventing в рабочей группе Eventing.

Установка

Следуйте инструкциям для установки на платформу вашего выбора.

Начало работы

Опубликовать ( 0 )

Вы можете оставить комментарий после Вход в систему

1
https://api.gitlife.ru/oschina-mirror/knative-docs.git
git@api.gitlife.ru:oschina-mirror/knative-docs.git
oschina-mirror
knative-docs
knative-docs
master