Biar saya mulakan dari awal. Dalam peranan saya sebagai Jurutera Awan AWS di salah seorang pelanggan saya sebelum ini, seni bina dipacu peristiwa telah digunakan di mana pihak ketiga sentiasa menghantar banyak acara ke persekitaran AWS kami melalui EventBridge. Untuk setiap pihak ketiga, kami menyediakan bas acara dengan pelbagai peraturan EventBridge.
Cabaran di sini ialah menjejaki struktur acara—cara ia dianjurkan. Acara kerap dikemas kini, membawa kepada banyak mesyuarat untuk menjelaskan perkara.
Pada penghujung tahun 2019, sebahagian besar masalah kami telah diselesaikan berkat Penemuan Skema EventBridge. Dengan mendayakan ini pada bas acara, skema dijana secara automatik berdasarkan acara yang diterima. Ini membolehkan kami menjana pengikatan kod daripada skema ini, yang merupakan bantuan besar dalam persekitaran berorientasikan objek kami.
Di bawah anda boleh melihat contoh acara yang sangat asas bagi pihak ketiga.
{ "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 menemui skema untuk jenis acara ini:
Dengan menggunakan Kit Alat AWS untuk Kod Visual Studio, kami boleh dengan mudah mewakili acara kami sebagai objek yang ditaip kuat dalam kod kami.
Di bawah ialah contoh yang sangat asas tentang cara kami menggunakan pengikatan kod.
Output:
123456789 C001 <class 'schema.com_company_a.ordertype.OrderType.OrderType'> <class 'dict'>
Ini menambah baik cara kami bekerja, tetapi kami masih menghadapi masalah. Dari semasa ke semasa, pihak ketiga akan menambah atribut baharu pada acara mereka. EventBridge akan menemui perubahan ini, tetapi pembangun sering terlupa untuk mengemas kini pengikatan kod untuk skema baharu. Walaupun pelaksanaan kami cukup teguh untuk mengelakkan kerosakan apabila atribut baharu ditambahkan, ia menghasilkan data baharu yang tidak kami gunakan. Kami terpaksa bergantung pada pembangun untuk ingat untuk mengemas kini pengikatan kod mereka sekali-sekala, dan tiada proses yang jelas disediakan untuk mengurus perkara ini.
Kadangkala pengikatan kod tidak dikemas kini selama berbulan-bulan dan kadangkala, dua pembangun akan mengemas kininya serentak, yang membawa kepada konflik atau kerja pendua.
Untuk menangani perkara ini dengan lebih baik, kami memutuskan untuk membina penyelesaian yang mencipta tiket Jira secara automatik apabila pihak ketiga mengemas kini acara mereka dan skema baharu ditemui.
Penyelesaian tersedia dalam CloudFormation pada GitHub saya. Semak README.
Langkah pertama ialah membuat peraturan EventBridge pada bas lalai kami yang akan mencetuskan apabila skema baharu atau kemas kini versi skema ditemui. Acara ini kemudiannya dihantar ke baris gilir SQS untuk berfungsi sebagai input untuk EventBridge Pipe. Di sini, kami boleh menambah penapisan tambahan (pilihan dalam contoh ini) dan memperkayakan acara kami menggunakan fungsi Lambda.
Untuk pengayaan, kami menggunakan describe_schema menggunakan 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"]), }
Selepas memperkaya data kami, kami menghantarnya ke aliran kerja Fungsi Langkah. Aliran kerja ini, seterusnya, mencetuskan AWS-CreateJiraIssue SSM Automation yang disediakan oleh AWS, yang mencipta tiket Jira secara automatik.
Tiket termasuk butiran seperti nama skema, versi skema baharu dan ARN skema. (Kandungan tambahan daripada acara juga boleh ditambah jika perlu.)
+----------------+ +--------+ +-------------------------+ +----------------+ +-------------------------+ | EventBridge | ---> | SQS | ---> | EventBridge Pipe | ---> | Step Function | ---> | SSM Automation Document | | Rule | | | | (Filtering & Enrichment)| | | | | +----------------+ +--------+ +-------------------------+ +----------------+ +-------------------------+
Jom demo penyelesaian ini. Di sini anda melihat acara yang dikemas kini, berdasarkan yang asal. Status atribut adalah baharu.
{ "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" } }
Skema baharu akan ditemui. Ini akan mencetuskan keseluruhan penyelesaian. Selepas Lambda memperkayakan acara kami, acara yang dikemas kini itu akan digunakan sebagai input untuk Fungsi Langkah kami.
Acara input Fungsi Langkah kami diperkaya dan kelihatan seperti ini.
[ { "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" } } } } } } } } ]
Aliran kerja Fungsi Langkah akan, seterusnya, mencetuskan automasi SSM dan mencipta Tiket Jira.
Untuk kemudahan, saya ringkaskan kandungan tiket. Walau bagaimanapun, memandangkan Kandungan juga dihantar sebagai input kepada Fungsi Langkah, ia juga boleh dimasukkan ke dalam tiket. Dengan cara itu, anda boleh menyebut secara langsung atribut baharu atau perubahan pada skema dalam tiket anda.
Penyelesaian ini juga akan dicetuskan apabila acara baharu sepenuhnya ditemui, kerana ia akan mencipta versi 1 acara baharu, menyebabkan peraturan EventBridge dicetuskan.
Dengan cara ini, kami dimaklumkan tentang kemas kini dan boleh menjadualkannya ke dalam pecut kami. Ini membawa kepada pecutan kitaran pembangunan kami.
Saya sedar bahawa ini adalah kes yang agak khusus, tetapi penyelesaian yang serupa boleh dibina dengan menyediakan peraturan EventBridge untuk mencetuskan peristiwa yang diingini, dan kemudian menggunakan Pengayaan dan Fungsi Langkah dalam kombinasi dengan SSM untuk mencipta automasi selanjutnya.
Atas ialah kandungan terperinci Mengendalikan Tiket Jira Automatik untuk Penemuan Skema EventBridge Baharu. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!