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

Задачей здесь было отслеживать структуру мероприятия — то, как оно было организовано. События часто обновлялись, что приводило к множеству встреч для разъяснения ситуации.

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

Ниже вы можете увидеть простой пример стороннего события.

{
  "version": "0",
  "id": "ef21d5fc-a5ba-e2c6-fc4b-a8807455c64d",
  "detail-type": "orderType",
  "source": "com.company.A",
  "account": "xxx",
  "time": "2024-08-22T08:04:26Z",
  "region": "eu-west-1",
  "resources": [],
  "detail": {
    "orderId": 123456789,
    "customer": {
      "customerId": "C001",
      "name": "John Doe"
    },
    "orderDate": "2024-08-22"
  }
}

AWS обнаружил схему для следующих типов событий:

Используя AWS Toolkit для Visual Studio Code, мы можем легко представлять наши события в нашем коде как строго типизированные объекты.

Ниже приведен очень простой пример того, как мы использовали привязки кода.

Выход:

123456789
C001

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

Иногда привязка кода не обновлялась месяцами, а иногда два разработчика обновляли его одновременно, что приводило к конфликтам или дублированию работы.

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

Решение доступно в CloudFormation на моем GitHub. Проверьте README.

Первым шагом было создание правила EventBridge на нашей шине по умолчанию, которое срабатывало бы при обнаружении новой схемы или обновления версии схемы. Затем это событие было отправлено в очередь SQS, чтобы служить входными данными для канала EventBridge. Здесь мы могли бы добавить дополнительную фильтрацию (необязательно в этом примере) и обогатить наше событие с помощью функции Lambda.

Для расширения мы использовали описание_схемы с использованием boto3.

data = event[0]["input"]["detail"]

try:
    response = client.describe_schema(
        RegistryName=data["RegistryName"],
        SchemaName=data["SchemaName"],
        SchemaVersion=data["Version"],
    )
except ClientError as e:
    raise e

return_data = {
    "SchemaName": response["SchemaName"],
    "SchemaVersion": response["SchemaVersion"],
    "SchemaArn": response["SchemaArn"],
    "Content": json.loads(response["Content"]),
}

После обогащения наших данных мы отправили их в рабочий процесс Step Function. Этот рабочий процесс, в свою очередь, активировал предоставленную AWS автоматизацию SSM AWS-CreateJiraIssue SSM, которая автоматически создала билет Jira.

Заявка включала такую ​​информацию, как имя схемы, новую версию схемы и ARN схемы. (При необходимости также можно добавить дополнительный контент с мероприятия.)

 ----------------        --------        -------------------------        ----------------        ------------------------- 
| EventBridge    | ---> | SQS    | ---> | EventBridge Pipe        | ---> | Step Function  | ---> | SSM Automation Document |
| Rule           |      |        |      | (Filtering & Enrichment)|      |                |      |                         |
 ----------------        --------        -------------------------        ----------------        ------------------------- 

Давайте продемонстрируем это решение. Здесь вы видите обновленное событие, основанное на оригинале. Статус атрибута новый.

{
  "version": "0",
  "id": "dffbd38b-9258-d028-21f3-da0ba3c9e314",
  "detail-type": "orderType",
  "source": "com.company.A",
  "account": "xxx",
  "time": "2024-08-22T08:04:26Z",
  "region": "eu-west-1",
  "resources": [],
  "detail": {
    "orderId": 123456789,
    "status": "Completed",
    "customer": {
      "customerId": "C001",
      "name": "John Doe"
    },
    "orderDate": "2024-08-22"
  }
}

Будет обнаружена новая схема. Это запустит все решение. После того, как Lambda дополнит наше событие, это обновленное событие будет использоваться в качестве входных данных для нашей пошаговой функции.

Входное событие нашей функции Step расширено и выглядит следующим образом.

[
  {
    "statusCode": 200,
    "data": {
      "SchemaName": "com.company.A@OrderType",
      "SchemaVersion": "2",
      "SchemaArn": "arn:aws:schemas:eu-west-1:xxx:schema/discovered-schemas/com.company.A@OrderType",
      "Content": {
        "openapi": "3.0.0",
        "info": {
          "version": "1.0.0",
          "title": "OrderType"
        },
        "paths": {},
        "components": {
          "schemas": {
            "AWSEvent": {
              "type": "object",
              "required": [
                "detail-type",
                "resources",
                "detail",
                "id",
                "source",
                "time",
                "region",
                "version",
                "account"
              ],
              "x-amazon-events-detail-type": "orderType",
              "x-amazon-events-source": "com.company.A",
              "properties": {
                "detail": {
                  "$ref": "#/components/schemas/OrderType"
                },
                "account": {
                  "type": "string"
                },
                "detail-type": {
                  "type": "string"
                },
                "id": {
                  "type": "string"
                },
                "region": {
                  "type": "string"
                },
                "resources": {
                  "type": "array",
                  "items": {
                    "type": "object"
                  }
                },
                "source": {
                  "type": "string"
                },
                "time": {
                  "type": "string",
                  "format": "date-time"
                },
                "version": {
                  "type": "string"
                }
              }
            },
            "OrderType": {
              "type": "object",
              "required": [
                "orderId",
                "orderDate",
                "customer",
                "status"
              ],
              "properties": {
                "customer": {
                  "$ref": "#/components/schemas/Customer"
                },
                "orderDate": {
                  "type": "string",
                  "format": "date"
                },
                "orderId": {
                  "type": "number"
                },
                "status": {
                  "type": "string"
                }
              }
            },
            "Customer": {
              "type": "object",
              "required": [
                "customerId",
                "name"
              ],
              "properties": {
                "customerId": {
                  "type": "string"
                },
                "name": {
                  "type": "string"
                }
              }
            }
          }
        }
      }
    }
  }
]

Рабочий процесс Step Function, в свою очередь, запускает автоматизацию SSM и создает заявку Jira.

Для удобства я оставил содержание заявки кратким. Однако, поскольку контент также отправляется в качестве входных данных для функции Step, его также можно включить в заявку. Таким образом, вы можете напрямую упомянуть новые атрибуты или изменения в схеме в своем запросе.

Это решение также будет срабатывать при обнаружении совершенно нового события, поскольку оно создаст версию 1 нового события, вызывающую срабатывание правила EventBridge.

Таким образом, мы были проинформированы об обновлениях и могли запланировать их в нашем спринте. Это приводит к ускорению нашего цикла разработки.

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