Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Pola Pub/sub
Ketika platform tumbuh, mungkin sulit bagi layanan mikro yang berbeda untuk berinteraksi tanpa menciptakan saling ketergantungan. Pola publish/subscribe (pub/sub) menyediakan komunikasi asinkron di antara beberapaAWSlayanan, seperti Amazon SQS, Lambda atau Amazon Simple Storage Service (Amazon S3), tanpa menciptakan ketergantungan. Dalam pola ini, layanan mikro mempublikasikan acara sebagai pesan di saluran yang dapat didengarkan pelanggan. Misalnya, pabrik dapat menggunakan pola pub/sub untuk memungkinkan peralatan mempublikasikan masalah atau kegagalan ke saluran, pelanggan kemudian dapat menampilkan dan mencatat masalah peralatan ini.
Anda harus mempertimbangkan untuk menggunakan pola ini jika:
-
Anda memiliki arsitektur yang didorong oleh acara.
-
Anda dapat mengaktifkan arsitektur longgar digabungkan.
-
Anda tidak perlu menyelesaikan semua bagian operasional transaksi sebelum respon kembali ke sistem panggilan (operasi tertentu dapat asynchronous).
-
Anda perlu menskalakan volume yang berada di luar kemampuan pusat data tradisional. Tingkat skalabilitas ini terutama disebabkan oleh operasi paralel, caching pesan, perutean berbasis pohon, dan fitur lainnya yang dibangun ke dalam model pub/sub.
Ada beberapa kelemahan untuk menggunakan pola ini. Misalnya, pola pub/sub biasanya tidak dapat menjamin pengiriman pesan ke semua jenis pelanggan, meskipun layanan tertentu seperti Amazon Simple Notification Service (Amazon SNS) dapat menyediakanpersis-sekalipengiriman ke beberapa subset pelanggan. Kerugian lain adalah bahwa penerbit dapat berasumsi bahwa pelanggan mendengarkan saluran ketika, pada kenyataannya, mereka tidak.
Kasus penggunaan
Dalam kasus penggunaan ini, topik SNS digunakan untuk mempublikasikan peristiwa ke beberapa layanan mikro tergantung dalam sistem asuransi. Setelah pelanggan melakukan pembayaran bulanan, informasi harus diperbarui dalam subsistem seperti “Pelanggan” atau “Penjualan,” dan email harus dikirim ke pelanggan dengan konfirmasi pembayaran. Pola ini dapat diimplementasikan dengan menggunakan Amazon SNS atau Amazon EventBridge.
EventBridge menyaring peristiwa antara beberapa pelanggan. Implementasi EventBridge menyediakan dua opsi berikut:
-
Kirim tiga acara dengan jenis acara yang berbeda. Target jauh mengambil mereka berdasarkan aturan acara.
-
Kirim satu pesan dengan tiga aturan acara mendengarkan jenis acara yang sama. Data yang tidak perlu disaring sebelum target tertentu dipanggil.
Implementasi Amazon SNS
Ilustrasi berikut menunjukkan bagaimana Amazon SNS digunakan untuk mengimplementasikan pola pub/sub. Setelah pengguna melakukan pembayaran, pesan SNS dikirim oleh fungsi “Pembayaran” Lambda ke topik SNS “Pembayaran”. Topik SNS ini memiliki tiga pelanggan yang menerima salinan pesan dan memprosesnya.
Implementasi Amazon EventBridge
Dalam ilustrasi berikut, EventBridge digunakan untuk membangun versi pola pub/sub di mana pelanggan didefinisikan dengan menggunakan aturan acara. Setelah pengguna melakukan pembayaran, fungsi “Pembayaran” Lambda mengirimkan pesan ke EventBridge dengan menggunakan bus acara default berdasarkan skema kustom yang memiliki tiga aturan berbeda yang menunjuk ke target yang berbeda. Setiap microservice memproses pesan dan melakukan tindakan yang diperlukan.
