让我从头开始。我在之前的一个客户中担任 AWS 云工程师，使用了一种事件驱动架构，第三方通过 EventBridge 不断向我们的 AWS 环境发送许多事件。对于每个第三方，我们提供了一个包含各种 EventBridge 规则的事件总线。
这里的挑战是跟踪活动结构——它是如何组织的。事件经常更新，导致召开许多会议来澄清事情。
2019 年底，由于 EventBridge Schema Discovery，我们的很大一部分问题得到了解决。通过在事件总线上启用此功能，可以根据接收到的事件自动生成模式。这使我们能够从这些模式生成代码绑定，这对我们的面向对象环境有很大帮助。
下面您可以看到一个非常基本的第三方示例事件。
{
"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 for Visual Studio Code，我们可以轻松地将事件表示为代码中的强类型对象。
下面是一个关于我们如何使用代码绑定的非常基本的示例。
输出：
123456789 C001 <class 'schema.com_company_a.ordertype.OrderType.OrderType'> <class 'dict'>
这改善了我们的工作方式，但我们仍然遇到了问题。有时，第三方会为其活动添加新属性。 EventBridge 会发现这些更改，但开发人员经常忘记更新新架构的代码绑定。尽管我们的实现足够强大，可以防止添加新属性时出现损坏，但它会产生我们没有利用的新数据。我们必须依靠开发人员记住偶尔更新他们的代码绑定，并且没有明确的流程来管理此操作。
有时代码绑定几个月都没有更新，有时两个开发人员会同时更新它，从而导致冲突或重复工作。
为了更好地处理这个问题，我们决定构建一个解决方案，每当第三方更新其事件并发现新架构时，该解决方案都会自动创建 Jira 票证。
该解决方案可在我的 GitHub 上的 CloudFormation 中找到。检查自述文件。
第一步是在我们的默认总线上创建一个 EventBridge 规则，每当发现新架构或架构版本更新时就会触发该规则。然后，该事件被发送到 SQS 队列，作为 EventBridge Pipe 的输入。在这里，我们可以添加额外的过滤（在本例中是可选的）并使用 Lambda 函数丰富我们的事件。
为了丰富，我们使用 boto3 来描述_schema。
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 提供的 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 Function 的输入。
我们的 Step Function 的输入事件更加丰富了，如下所示。
[
{
"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 Ticket。
为了方便起见，我将门票内容保持简短。但是，由于内容也作为输入发送到 Step Function，因此它也可以包含在票证中。这样，您就可以在工单中直接提及新属性或架构更改。
当发现全新事件时，也会触发此解决方案，因为它将创建新事件的版本 1，从而导致 EventBridge 规则触发。
通过这种方式，我们了解了更新并可以将它们安排到我们的冲刺中。这会加快我们的开发周期。
我知道这是一个非常具体的案例，但可以通过设置 EventBridge 规则来触发所需的事件来构建类似的解决方案，然后将丰富功能和 Step Functions 与 SSM 结合使用来创建进一步的自动化。
以上是处理新 EventBridge 架构发现的自动 Jira 票证的详细内容。更多信息请关注PHP中文网其他相关文章！
