讓我從頭開始。我在之前的客戶中擔任 AWS 雲端工程師，使用了事件驅動架構，第三方透過 EventBridge 不斷向我們的 AWS 環境發送許多事件。對於每個第三方，我們提供了一個包含各種 EventBridge 規則的事件匯流排。
這裡的挑戰是追蹤活動結構——它是如何組織的。活動經常更新，導致召開許多會議來澄清事情。
2019 年底，我們有很大一部分的問題透過 EventBridge Schema Discovery 解決了。透過在事件總線上啟用此功能，可以根據接收到的事件自動產生模式。這使我們能夠從這些模式產生程式碼綁定，這對我們的物件導向環境有很大幫助。
下面你可以看到一個非常基本的第三方範例事件。
AWS 發現了這些類型事件的模式：
透過使用 AWS Toolkit for Visual Studio Code，我們可以輕鬆地將事件表示為程式碼中的強型別物件。
下面是一個關於我們如何使用程式碼綁定的非常基本的範例。
輸出：
這改善了我們的工作方式，但我們仍然遇到了問題。有時，第三方會為其活動新增屬性。 EventBridge 會發現這些更改，但開發人員經常忘記更新新架構的程式碼綁定。儘管我們的實作足夠強大，可以防止添加新屬性時出現損壞，但它會產生我們沒有利用的新資料。我們必須依靠開發人員記住偶爾更新他們的程式碼綁定，並且沒有明確的流程來管理這一點。
有時，程式碼綁定幾個月都沒有更新，有時兩個開發人員會同時更新它，導致衝突或重複工作。
為了更好地處理這個問題，我們決定建立一個解決方案，每當第三方更新其事件並發現新架構時，該解決方案都會自動建立 Jira 票證。
解決方案可以在我的 GitHub 上的 CloudFormation 中找到。檢查自述文件。
第一步是在我們的預設匯流排上建立一個 EventBridge 規則，每當發現新架構或架構版本更新時就會觸發該規則。然後，該事件被傳送到 SQS 佇列，作為 EventBridge 管道的輸入。在這裡，我們可以添加額外的過濾（在本例中是可選的）並使用 Lambda 函數豐富我們的事件。
為了豐富，我們使用 boto3 來描述_schema。
豐富資料後，我們將其發送到 Step Function 工作流程。此工作流程又觸發了 AWS 提供的 AWS-CreateJiraIssue SSM 自動化，自動建立 Jira 票證。
票證包含架構名稱、新架構版本和架構的 ARN 等詳細資訊。 （如有需要，也可以加入活動的其他內容。）
讓我們來示範這個解決方案。在這裡您可以看到基於原始事件的更新事件。屬性狀態為新。
將會發現一個新的模式。這將觸發整個解決方案。 Lambda 豐富了我們的事件後，更新後的事件將用作我們 Step Function 的輸入。
我們的Step Function的輸入事件豐富了，看起來像這樣
Step Function 工作流程將依序觸發 SSM 自動化並建立 Jira Ticket。
為了方便起見，我將門票內容保持簡短。但是，由於內容也作為輸入發送到 Step Function，因此它也可以包含在票證中。這樣，您就可以在工單中直接提及新屬性或架構變更。
當發現全新事件時，也會觸發此解決方案，因為它將建立新事件的版本 1，從而導致 EventBridge 規則觸發。
透過這種方式，我們就可以獲知更新情況，並且可以將它們安排到我們的衝刺中。這會加快我們的開發週期。
我知道這是一個非常具體的案例，但可以透過設定 EventBridge 規則來觸發所需的事件來建立類似的解決方案，然後將豐富和 Step Functions 與 SSM 結合使用來創建進一步的自動化。
以上是處理新 EventBridge 架構發現的自動 Jira 票證的詳細內容。更多資訊請關注PHP中文網其他相關文章！
