Olahpesan asinkron dan penerusan kejadian - Menerapkan Layanan Mikro di AWS

Olahpesan asinkron dan penerusan kejadian

Penerusan pesan adalah pola tambahan yang digunakan untuk menerapkan komunikasi di antara layanan mikro. Layanan berkomunikasi dengan bertukar pesan melalui antrean. Salah satu manfaat utama dari gaya komunikasi ini adalah tidak memerlukan penemuan layanan dan layanannya tidak di-coupling secara erat.

Sistem sinkron memiliki coupling yang erat, yang berarti masalah dalam dependensi downstream sinkron akan memiliki dampak langsung pada pemanggil upstream. Percobaan ulang dari pemanggil upstream dapat menyebarkan dan memperbesar masalah dengan cepat.

Bergantung pada persyaratan tertentu, seperti protokol, AWS menawarkan berbagai layanan yang membantu menerapkan pola ini. Satu kemungkinan penerapan menggunakan kombinasi antrean Amazon Simple Queue Service (Amazon SQS) atau Amazon Simple Notification Service (Amazon SNS).

Kedua layanan ini beroperasi bersama secara erat: Amazon SNS memungkinkan aplikasi mengirimkan pesan ke beberapa pelanggan melalui mekanisme push. Dengan Amazon SNS dan Amazon SQS bersama-sama, satu pesan dapat dikirimkan ke beberapa konsumen. Gambar berikut menampilkan integrasi Amazon SNS dan Amazon SQS.

Pola bus pesan di AWS

Jika Anda mengatur antrean Amazon SQS agar berlangganan topik SNS, Anda dapat memublikasikan pesan ke topik tersebut, dan Amazon SNS akan mengirimkan sebuah pesan ke antrean Amazon SQS yang berlangganan. Pesan ini berisi subjek dan pesan yang dipublikasikan ke topik bersama dengan informasi metadata dalam format JSON.

Opsi lain untuk membangun arsitektur berbasis kejadian dengan event sourcing yang mencakup aplikasi internal, aplikasi SaaS pihak ketiga, dan layanan AWS dalam skala besar adalah Amazon EventBridge. Sebagai layanan bus kejadian terkelola penuh, EventBridge akan menerima kejadian dari sumber yang berbeda-beda, mengidentifikasi target berdasarkan aturan perutean, dan mengirimkan data secara hampir waktu nyata ke target tersebut, termasuk AWS Lambda, Amazon SNS, Amazon Kinesis Streams, dll. Kejadian yang masuk juga dapat disesuaikan oleh input transformer sebelum pengiriman.

Untuk pengembangan aplikasi berbasis kejadian yang secara signifikan lebih cepat, registri skema EventBridge akan mengumpulkan dan mengatur skema, termasuk skema untuk semua kejadian yang dihasilkan oleh layanan AWS. Pelanggan juga dapat menentukan skema kustom atau menggunakan opsi Infer Schema (Inferensikan Skema) untuk menemukan skema secara otomatis. Namun setelah mempertimbangkan segala aspeknya, semua fitur tersebut disertai dengan sebuah potensi kerugian, yaitu nilai latensi yang relatif lebih tinggi untuk pengiriman EventBridge. Selain itu, throughput dan kuota default untuk EventBridge mungkin memerlukan penambahan berdasarkan kasus penggunaannya, yang dapat dilakukan dengan mengajukan permintaan dukungan.

Sebuah strategi penerapan yang berbeda berdasarkan Amazon MQ dapat digunakan jika perangkat lunak yang ada menggunakan API dan protokol standar terbuka untuk olahpesan, termasuk JMS, NMS, AMQP, STOMP, MQTT, dan WebSocket. Amazon SQS akan mengekspos API kustom. Dengan demikian, jika Anda memiliki aplikasi yang sudah ada yang ingin dimigrasikan dari—misalnya, lingkungan on-premise ke AWS—maka perubahan kode diperlukan. Dengan Amazon MQ, dalam banyak kasus, hal ini tidak diperlukan.

Amazon MQ mengelola administrasi dan pemeliharaan ActiveMQ, broker pesan sumber terbuka yang populer. Infrastruktur yang mendasarinya secara otomatis disediakan untuk ketersediaan tinggi dan ketahanan pesan untuk mendukung keandalan aplikasi Anda.