Pilih apakah akan menggunakan pesan atau kejadian
Misalkan Anda merencanakan arsitektur aplikasi berbagi musik terdistribusi. Anda ingin memastikan bahwa aplikasi ini dapat diandalkan dan dapat diskalakan, dan Anda bermaksud menggunakan teknologi Azure untuk membangun infrastruktur komunikasi yang kuat.
Sebelum Anda dapat memilih teknologi Azure yang tepat, Anda harus memahami setiap komunikasi individual dengan komponen pertukaran aplikasi. Untuk setiap komunikasi, Anda dapat memilih teknologi Azure yang berbeda.
Hal pertama yang perlu dipahami tentang komunikasi adalah apakah ia mengirim pesan atau kejadian. Pengetahuan ini membantu Anda memilih layanan Azure yang sesuai untuk digunakan.
Strategi komunikasi di Azure (API)
Apa itu pesan?
Dalam terminologi aplikasi terdistribusi,pesan memiliki karakteristik berikut:
- Pesan berisi data mentah, diproduksi oleh satu komponen dan dikonsumsi oleh komponen lain.
- Pesan berisi data itu sendiri, bukan hanya referensi ke data tersebut.
- Komponen pengirim mengharapkan komponen tujuan untuk memproses konten pesan dengan cara tertentu. Integritas sistem secara keseluruhan mungkin bergantung pada pengirim dan penerima yang melakukan pekerjaan tertentu.
Misalnya, pengguna mengunggah lagu baru dengan menggunakan aplikasi berbagi musik seluler. Aplikasi seluler harus mengirim lagu tersebut ke API web, yang berjalan di Azure. File media lagu itu sendiri harus dikirim, bukan hanya pemberitahuan yang menunjukkan bahwa lagu baru telah ditambahkan. Aplikasi seluler mengharapkan bahwa API web menyimpan lagu baru dalam database dan membuatnya tersedia untuk pengguna lain. Ini adalah contoh pesan.
Apa itu kejadian?
Peristiwa lebih ringan daripada pesan, dan paling sering digunakan untuk komunikasi siaran. Komponen yang mengirim kejadian dikenal sebagai penerbit,dan penerima dikenal sebagai pelanggan.
Dengan peristiwa, komponen penerima memutuskan komunikasi mana yang mereka minati, dan "berlangganan" ke peristiwa tersebut. Perantara mengelola langganan, seperti Azure Event Grid atau Azure Event Hubs. Saat penerbit mengirim peristiwa, perantara merutekan peristiwa tersebut ke pelanggan yang tertarik. Pola ini dikenal sebagai "arsitektur terbitkan-berlangganan." Ini bukan satu-satunya cara untuk menangani peristiwa, tetapi ini adalah yang paling umum.
Kejadian memiliki karakteristik berikut:
- Kejadian adalah pemberitahuan ringan yang menunjukkan bahwa sesuatu terjadi.
- Kejadian dapat dikirim ke beberapa penerima, atau tidak sama sekali.
- Kejadian sering dimaksudkan untuk "fan out," atau memiliki sejumlah besar pelanggan untuk setiap penerbit.
- Penerbit kejadian tidak memiliki harapan tentang tindakan yang dilakukan komponen penerima.
- Beberapa kejadian adalah unit diskrit dan tidak terkait dengan kejadian lain.
- Beberapa kejadian adalah bagian dari seri terkait dan dipesan.
Misalnya, unggahan file musik telah selesai, dan lagu baru telah ditambahkan ke database. Untuk memberi tahu pengguna file baru, WEB API harus memberi tahu pengguna web front end dan aplikasi seluler file baru. Pengguna dapat memilih apakah akan mendengarkan lagu baru, sehingga pemberitahuan awal tidak menyertakan file musik tetapi hanya memberi tahu pengguna bahwa lagu tersebut ada. Pengirim tidak memiliki harapan khusus bahwa penerima peristiwa melakukan apa pun khususnya sebagai respons terhadap peristiwa ini.
Skenario ini adalah contoh kejadian diskrit.
Cara memilih pesan atau kejadian
Satu aplikasi kemungkinan menggunakan kejadian untuk beberapa tujuan dan pesan untuk orang lain. Sebelum memilih, Anda harus menganalisis arsitektur aplikasi dan semua kasus penggunaannya untuk mengidentifikasi semua tujuan yang berbeda di mana komponennya harus berkomunikasi satu sama lain.
Peristiwa lebih mungkin digunakan untuk siaran, dan sering bersifat sementara. Ini berarti komunikasi mungkin tidak ditangani oleh penerima apa pun jika saat ini tidak ada yang berlangganan. Pesan lebih mungkin digunakan di mana aplikasi yang didistribusikan memerlukan jaminan bahwa komunikasi akan diproses.
Untuk setiap komunikasi, pertimbangkan pertanyaan berikut: Apakah komponen pengirim mengharapkan komunikasi diproses dengan cara tertentu oleh komponen tujuan?
Jika jawabannya adalah ya, pilih untuk menggunakan pesan. Jika jawabannya tidak, Anda mungkin dapat menggunakan peristiwa.
Memahami bagaimana komponen Anda perlu berkomunikasi membantu Anda memilih bagaimana komponen Anda berkomunikasi. Mari kita mulai dengan pesan.