Маршрутизация событий заказов с EventBridge

AWSBeginner
Практиковаться сейчас

Введение

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

EventBridge отбирает входящие события и направляет их в SQS — очередь, которая хранит сообщения. Доступ через CLI уже настроен; личная учётная запись AWS и ключи доступа не нужны.

Сначала выполните Отправку и потребление заданий с SQS и Защиту бакета ресурсной политикой. Эта независимая VM предоставляет собственный доступ CLI и эталонные данные; прежние очереди и учётные данные не используются.

Связь с сертификацией

Сертификация Задача экзамена Практика
Cloud Practitioner (CLF-C02) Задача 3.8 Сопоставление событий EventBridge, цели и авторизация доставки.
Solutions Architect – Associate (SAA-C03) Задача 2.1 Сопоставление событий EventBridge, цели и авторизация доставки.
Developer – Associate (DVA-C02) Задача 1.1 Сопоставление событий EventBridge, цели и авторизация доставки.
CloudOps Engineer – Associate (SOA-C03) Задача 1.2 Сопоставление событий EventBridge, цели и авторизация доставки.
DevOps Engineer – Professional (DOP-C02) Задача 4.3 Базовая практика: Сопоставление событий EventBridge, цели и авторизация доставки.
Data Engineer – Associate (DEA-C01) Задача 3.1 Базовая практика: Сопоставление событий EventBridge, цели и авторизация доставки.

Обзор лабораторной работы

Концептуальная схема: пользовательская шина и правило EventBridge отбирают новые заказы для очереди SQS; её политика разрешает доставку от одного исходного правила, а AWS CLI и AWS View показывают фактические сообщения.

Подготовка шины и очереди назначения

На этом шаге создайте независимые места, куда поступают события и где совпадающая работа ожидает потребителя.

Используйте AWS View вверху, чтобы сравнивать запросы CLI с реальными ресурсами и результатами этой работы. Сохраните предоставленные эталонные данные.

Amazon EventBridge направляет события, описывающие произошедшее. Шина получает события, правило сопоставляет поля, а цель получает совпадающие события. Собственная шина отделяет события приложения от шины по умолчанию. Очередь SQS хранит доставки до их обработки потребителем. Начните в каталоге проекта. Присваивания оболочки сохраняют идентификаторы, возвращённые CLI; --query выбирает нужное поле, а --output text делает его пригодным для следующей команды.

cd /home/labex/project
BUS_NAME=labex-ev01-bus

Задайте RULE_NAME для следующих операций:

RULE_NAME=labex-ev01-orders

Создайте шину событий упражнения:

aws events create-event-bus --name "$BUS_NAME"

Сохраните возвращённое значение в QUEUE_URL:

QUEUE_URL=$(aws sqs create-queue \
  --queue-name labex-ev01-jobs \
  --query QueueUrl \
  --output text)
echo "$QUEUE_URL"

Сохраните возвращённое значение в QUEUE_ARN:

QUEUE_ARN=$(aws sqs get-queue-attributes \
  --queue-url "$QUEUE_URL" \
  --attribute-names QueueArn \
  --query Attributes.QueueArn \
  --output text)
echo "$QUEUE_ARN"

Ответ шины содержит её ARN, а QUEUE_URL определяет очередь для операций с сообщениями. ARN очереди определяет её в цели или политике разрешений. Эти идентификаторы служат разным целям.

Проверьте оба пустых ресурса:

aws events list-rules --event-bus-name "$BUS_NAME"

Просмотрите атрибуты очереди $QUEUE_URL:

aws sqs get-queue-attributes \
  --queue-url "$QUEUE_URL" \
  --attribute-names ApproximateNumberOfMessages ApproximateNumberOfMessagesNotVisible

Правил пока нет, а очередь не содержит доступных или обрабатываемых сообщений. AWS View показывает вашу собственную шину и пустую очередь. Выполните проверку подготовки.

Сопоставление заказов и авторизация одного правила

На этом шаге подключите правило сопоставления к очереди и авторизуйте доставки только этого правила.

Производитель, шина, правило и очередь — Совпадающее правило выбирает событие; разрешение очереди для исходного правила отдельно допускает его доставку.

Шаблон события — фильтр полей события. source называет производителя, а detail-type — категорию события. Каждый массив ниже перечисляет допустимые значения. Here-document записывает буквальный JSON между маркерами JSON; кавычки маркера предотвращают подстановки оболочки. file:// указывает CLI читать этот файл.

Оба поля шаблона должны совпасть: один лишь производитель заказов не выбирает отмену, а один лишь тип OrderPlaced не выбирает событие оплаты. Поле source события — данные маршрутизации; aws:SourceArn в политике очереди обозначает правило, которому разрешена доставка.

cat > order-pattern.json <<'JSON'
{"source":["labex.orders"],"detail-type":["OrderPlaced"]}
JSON

Сохраните возвращённое значение в RULE_ARN:

RULE_ARN=$(aws events put-rule \
  --name "$RULE_NAME" \
  --event-bus-name "$BUS_NAME" \
  --event-pattern file://order-pattern.json \
  --state ENABLED \
  --query RuleArn \
  --output text)
echo "$RULE_ARN"

Правило включено, но одно совпадение не авторизует доставку. Ресурсная политика очереди должна разрешать отправку сервису EventBridge с ограничением aws:SourceArn этим правилом. Запишите обычную политику JSON; оболочка подставляет ARN вашей очереди и правила.

cat > queue-policy.json <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "events.amazonaws.com"
      },
      "Action": "sqs:SendMessage",
      "Resource": "$QUEUE_ARN",
      "Condition": {
        "ArnEquals": {
          "aws:SourceArn": "$RULE_ARN"
        }
      }
    }
  ]
}
EOF

Запишите конфигурацию в queue-attributes.json:

jq -n --rawfile policy queue-policy.json '{Policy:$policy}' > queue-attributes.json

Примените атрибуты к очереди $QUEUE_URL:

aws sqs set-queue-attributes \
  --queue-url "$QUEUE_URL" \
  --attributes file://queue-attributes.json

API атрибутов хранит политику как строку JSON, поэтому --rawfile читает этот документ в атрибут Policy. Разрешение охватывает одну очередь и одно исходное правило.

Цель — место назначения правила. Её идентификатор позволяет позже обновить или удалить это подключение:

cat > targets.json <<EOF
[
  {
    "Id": "order-queue",
    "Arn": "$QUEUE_ARN"
  }
]
EOF

Примените цели доставки правила событий:

aws events put-targets \
  --rule "$RULE_NAME" \
  --event-bus-name "$BUS_NAME" \
  --targets file://targets.json

Просмотрите шаблон отбора правила событий:

aws events describe-rule --name "$RULE_NAME" --event-bus-name "$BUS_NAME"

Просмотрите цели доставки правила событий:

aws events list-targets-by-rule --rule "$RULE_NAME" --event-bus-name "$BUS_NAME"

FailedEntryCount равен нулю для конфигурации цели, описанное правило имеет нужный шаблон, а ARN цели соответствует вашей очереди. Теперь AWS View показывает правило и его очередь назначения. События для доставки пока нет. Выполните проверку подключения.

Подтверждение границ сопоставления и доставки

На этом шаге опубликуйте совпадающие и несвязанные события, затем проверьте отсутствие разрешения источника без добавления нового сообщения очереди.

Событие EventBridge имеет поля маршрутизации и полезную нагрузку detail. API PutEvents принимает Detail как строку, закодированную в JSON. Запишите три читаемые записи: один размещённый заказ, одно событие оплаты и одну отмену. jq преобразует каждый объект Detail в требуемую API строку.

cat > event-inputs.json <<EOF
[
  {
    "EventBusName": "$BUS_NAME",
    "Source": "labex.orders",
    "DetailType": "OrderPlaced",
    "Detail": {
      "id": "route-order",
      "quantity": 2
    }
  },
  {
    "EventBusName": "$BUS_NAME",
    "Source": "labex.billing",
    "DetailType": "OrderPlaced",
    "Detail": {
      "id": "billing-event",
      "quantity": 9
    }
  },
  {
    "EventBusName": "$BUS_NAME",
    "Source": "labex.orders",
    "DetailType": "OrderCancelled",
    "Detail": {
      "id": "cancelled-event",
      "quantity": 1
    }
  }
]
EOF

Запишите конфигурацию в events.json:

jq 'map(.Detail |= tojson)' event-inputs.json > events.json

Опубликуйте предоставленный пакет событий:

aws events put-events --entries file://events.json

Просмотрите атрибуты очереди $QUEUE_URL:

aws sqs get-queue-attributes \
  --queue-url "$QUEUE_URL" \
  --attribute-names ApproximateNumberOfMessages ApproximateNumberOfMessagesNotVisible

Ответ публикации сообщает о нуле неудачных записей и идентификаторе события для каждой принятой записи. Только route-order совпадает с обоими полями, поэтому очередь содержит одно доступное сообщение. AWS View показывает полный конверт события: источник, тип detail, аккаунт, регион и detail.

Прочитайте действительное тело, видимое потребителю. Получение обычно скрывает сообщение на время тайм-аута видимости; --visibility-timeout 0 делает эту проверку немедленно видимой снова. Запрос выводит только идентификатор и тело, исключая дескриптор получения из отображения. Эта проверка не завершает бизнес-обработку и не подтверждает сообщение.

fromjson делает каждое тело JSON читаемым, сохраняя его идентификатор сообщения SQS. Он меняет только отображаемый вывод.

aws sqs receive-message \
  --queue-url "$QUEUE_URL" \
  --max-number-of-messages 10 \
  --visibility-timeout 0 \
  --output json | jq '[.Messages[] | {MessageId, Body: (.Body | fromjson)}]'

В теле detail.id равен route-order, а detail.quantity равен 2. Записи оплаты и отмены не поступили в эту очередь.

AWS View показывает совпадающее событие заказа в очереди назначения — Пример ниже показывает включённое правило сопоставления, его цель очереди и реальное полное событие заказа, включая аккаунт и регион.

Теперь укажите другой ARN источника в политике очереди, сохранив правило и цель включёнными:

jq --arg wrong "${RULE_ARN}-other" '.Statement[0].Condition.ArnEquals["aws:SourceArn"]=$wrong' queue-policy.json > wrong-source-policy.json

Запишите конфигурацию в wrong-source-attributes.json:

jq -n --rawfile policy wrong-source-policy.json '{Policy:$policy}' > wrong-source-attributes.json

Примените атрибуты к очереди $QUEUE_URL:

aws sqs set-queue-attributes \
  --queue-url "$QUEUE_URL" \
  --attributes file://wrong-source-attributes.json

Запишите приведённое определение в event-inputs.json:

cat > event-inputs.json <<EOF
[
  {
    "EventBusName": "$BUS_NAME",
    "Source": "labex.orders",
    "DetailType": "OrderPlaced",
    "Detail": {
      "id": "denied-order",
      "quantity": 4
    }
  }
]
EOF

Запишите конфигурацию в denied-event.json:

jq 'map(.Detail |= tojson)' event-inputs.json > denied-event.json

Опубликуйте предоставленный пакет событий:

aws events put-events --entries file://denied-event.json

Просмотрите атрибуты очереди $QUEUE_URL:

aws sqs get-queue-attributes \
  --queue-url "$QUEUE_URL" \
  --attribute-names ApproximateNumberOfMessages ApproximateNumberOfMessagesNotVisible

EventBridge принимает это событие, но у правила нет требуемого разрешения очереди. Исходное сообщение остаётся единственным событием в очереди; denied-order отсутствует. При диагностике конвейера различайте принятие события и доставку цели. Это упражнение не исследует повторные попытки доставки.

Восстановите нужное разрешение и проверьте снова:

aws sqs set-queue-attributes \
  --queue-url "$QUEUE_URL" \
  --attributes file://queue-attributes.json

Прочитайте доставленные сообщения из очереди $QUEUE_URL:

aws sqs receive-message \
  --queue-url "$QUEUE_URL" \
  --max-number-of-messages 10 \
  --visibility-timeout 0 \
  --output json | jq '[.Messages[] | {MessageId, Body: (.Body | fromjson)}]'

Присутствует только исходный route-order. Исправленная политика авторизует последующие доставки; эта работа не зависит от повторной попытки ранее отклонённого события. Выполните проверку маршрутизации.

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

На этом шаге удалите свою цель, правило, собственную шину и временную очередь, сохранив несвязанные ресурсы.

Удалите цель перед удалением её правила. Затем удалите собственную шину и очередь. Удаление очереди отбрасывает синтетическое событие, сохранённое для проверки маршрутизации; его бизнес-результат не заявлялся.

aws events remove-targets \
  --rule "$RULE_NAME" \
  --event-bus-name "$BUS_NAME" \
  --ids order-queue

Удалите только правило событий упражнения:

aws events delete-rule --name "$RULE_NAME" --event-bus-name "$BUS_NAME"

Удалите только шину событий упражнения:

aws events delete-event-bus --name "$BUS_NAME"

Удалите очередь упражнения $QUEUE_URL:

aws sqs delete-queue --queue-url "$QUEUE_URL"

Успешные запросы только для чтения устанавливают оставшиеся ресурсы:

aws events list-event-buses

Просмотрите оставшиеся правила событий:

aws events list-rules --event-bus-name default

Просмотрите оставшиеся очереди SQS:

aws sqs list-queues

Просмотрите не затронутую упражнением контрольную запись:

aws dynamodb scan --table-name labex-ev01-reference --query Items

Остаётся только шина по умолчанию, её список правил пуст, URL очередей отсутствуют, а эталонная запись содержит keep unchanged. Ошибки аутентификации или сети не подтверждают удаление. AWS View показывает пустые списки пользовательских ресурсов и сохранённый эталон.

Удалите созданные вами обычные файлы:

rm -f event-inputs.json order-pattern.json queue-policy.json queue-attributes.json targets.json events.json wrong-source-policy.json wrong-source-attributes.json denied-event.json

Выполните проверку очистки перед завершением VM.

Резюме

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

Следующая работа преобразует конверт события в меньшую полезную нагрузку, необходимую потребителю очереди.

Подробнее см. в документации AWS: Шаблоны событий и сопоставление полей; Политики целевых ресурсов и разрешения доставки.