處理新 EventBridge 架構發現的自動 Jira 票證
- PHPz原創
- 2024-08-27 06:35:021064瀏覽
讓我從頭開始。我在之前的客戶中擔任 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 管道的輸入。在這裡，我們可以添加額外的過濾（在本例中是可選的）並使用 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中文網其他相關文章！