Artikel ini menjelaskan berbagai jenis pesan dan entitas yang berpartisipasi dalam infrastruktur olahpesan. Berdasarkan persyaratan setiap jenis pesan, artikel merekomendasikan layanan olahpesan Azure. Opsinya termasuk Azure Bus Layanan Messaging, Azure Event Grid, dan Azure Event Hubs. Untuk perbandingan produk, lihat Membandingkan layanan olahpesan.
Pada tingkat arsitektur, pesan adalah datagram yang dibuat oleh entitas (produsen), untuk mendistribusikan informasi sehingga entitas lain (konsumen) dapat mengetahui dan bertindak sesuai dengan itu. Produsen dan konsumen dapat berkomunikasi secara langsung atau opsional melalui entitas perantara (perantara pesan). Artikel ini berfokus pada pesan asinkron menggunakan perantara pesan.
Kita dapat mengklasifikasikan pesan ke dalam dua kategori utama. Jika produsen mengharapkan tindakan dari konsumen, pesan itu adalah perintah. Jika pesan tersebut memberi tahu konsumen bahwa suatu tindakan telah terjadi, maka pesan tersebut adalah peristiwa.
Perintah
Produsen mengirimkan perintah dengan niat bahwa konsumen akan melakukan operasi dalam cakupan transaksi bisnis.
Perintah adalah pesan bernilai tinggi dan harus disampaikan setidaknya sekali. Jika perintah hilang, seluruh transaksi bisnis mungkin gagal. Selain itu, perintah tidak boleh diproses lebih dari sekali. Melakukan hal tersebut dapat menyebabkan transaksi yang salah. Pelanggan mungkin mendapatkan pesanan duplikat atau ditagih dua kali.
Perintah sering digunakan untuk mengelola alur kerja transaksi bisnis multilangkah. Tergantung pada logika bisnis, produsen mungkin mengharapkan konsumen untuk mengakui pesan dan melaporkan hasil operasi. Berdasarkan hasil tersebut, produser mungkin memilih tindakan yang sesuai.
Aktivitas
Peristiwa adalah jenis pesan yang diangkat oleh produsen untuk mengumumkan fakta.
Produser (dikenal sebagai penerbit dalam konteks ini) tidak memiliki harapan bahwa peristiwa menghasilkan tindakan apa pun.
Konsumen yang tertarik dapat berlangganan, mendengarkan peristiwa, dan mengambil tindakan tergantung pada skenario konsumsi mereka. Peristiwa dapat memiliki banyak pelanggan atau tidak memiliki pelanggan sama sekali. Dua pelanggan yang berbeda dapat bereaksi terhadap suatu peristiwa dengan tindakan yang berbeda dan tidak menyadari satu sama lain.
Produsen dan konsumen secara longgar digabungkan dan dikelola secara independen. Produsen tidak mengharapkan konsumen untuk mengakui peristiwa kembali kepada produsen. Konsumen yang tidak lagi tertarik dengan peristiwa dapat berhenti berlangganan, yang menghapus konsumen dari alur tanpa memengaruhi produsen atau fungsionalitas keseluruhan sistem.
Ada dua kategori peristiwa:
Produsen memunculkan peristiwa untuk mengumumkan fakta terpisah. Kasus penggunaan umum adalah notifikasi kejadian. Misalnya, Azure Resource Manager memunculkan peristiwa saat membuat, mengubah, atau menghapus sumber daya. Pelanggan dari peristiwa tersebut bisa menjadi Logic App yang mengirimkan email peringatan.
Produsen memunculkan peristiwa terkait dalam urutan, atau aliran peristiwa, selama periode waktu tertentu. Biasanya, aliran digunakan untuk evaluasi statistik. Evaluasi dapat terjadi dalam jendela temporal atau saat peristiwa tiba. Telemetri adalah kasus penggunaan umum (misalnya, pemantauan kesehatan dan beban sistem). Kasus lainnya adalah streaming peristiwa dari perangkat IoT.
Pola umum untuk menerapkan pesan peristiwa adalah pola Penerbit-Pelanggan.
Perantara dan manfaat perantara pesan
Broker pesan perantara menyediakan fungsionalitas pemindahan pesan dari produsen ke konsumen dan dapat menawarkan lebih banyak manfaat.
Pemisahan
Perantara pesan memisahkan produsen dari konsumen dalam logika yang menghasilkan dan menggunakan pesan, masing-masing. Dalam alur kerja yang kompleks, perantara dapat mendorong operasi bisnis untuk dipisahkan dan membantu mengoordinasikan alur kerja.
Misalnya, satu transaksi bisnis memerlukan operasi berbeda yang dilakukan dalam urutan logika bisnis. Produsen mengeluarkan perintah yang memberi sinyal kepada konsumen untuk memulai operasi. Konsumen mengakui pesan dalam antrean terpisah yang disediakan untuk mengantre tanggapan untuk produsen. Hanya setelah menerima respons, produsen mengirim pesan baru untuk memulai operasi berikutnya secara berurutan. Konsumen yang berbeda memproses pesan itu dan mengirimkan pesan penyelesaian ke antrean respons. Menggunakan olahpesan, layanan mengoordinasikan alur kerja transaksi di antara mereka sendiri.
Perantara pesan menyediakan pemisahan sementara. Produsen dan konsumen tidak harus berjalan secara bersamaan. Produsen dapat mengirim pesan ke perantara pesan terlepas dari ketersediaan konsumen. Sebaliknya, konsumen tidak dibatasi oleh ketersediaan produsen.
Misalnya, antarmuka pengguna aplikasi web menghasilkan pesan dan menggunakan antrean sebagai perantara pesan. Ketika konsumen siap, konsumen dapat mengambil pesan dari antrean dan melakukan pekerjaan. Pemisahan sementara membantu antarmuka pengguna untuk tetap responsif. Ini tidak diblokir saat pesan ditangani secara asinkron.
Operasi tertentu bisa memakan waktu lama untuk diselesaikan. Setelah mengeluarkan perintah, produsen seharusnya tidak perlu menunggu sampai konsumen menyelesaikannya. Perantara pesan membantu pemrosesan pesan asinkron.
Penyeimbangan Beban
Produsen dapat memposting sejumlah besar pesan yang dilayankan oleh banyak konsumen. Gunakan perantara pesan untuk mendistribusikan pemrosesan di seluruh server dan meningkatkan throughput. Konsumen dapat berjalan di server yang berbeda untuk menyebarkan beban. Konsumen dapat ditambahkan secara dinamis untuk meluaskan skala sistem saat dibutuhkan atau dihapus jika tidak.
Pola Konsumen yang Bersaing menjelaskan cara memproses beberapa pesan secara bersamaan untuk mengoptimalkan throughput, meningkatkan skalabilitas dan ketersediaan, dan menyeimbangkan beban kerja.
Tingkatan beban
Volume pesan yang dihasilkan oleh produsen atau sekelompok produsen dapat bervariasi. Terkadang mungkin ada volume besar yang menyebabkan lonjakan pesan. Daripada menambahkan konsumen untuk menangani pekerjaan ini, perantara pesan dapat bertindak sebagai buffer, dan konsumen secara bertahap mengalirkan pesan dengan kecepatan mereka sendiri tanpa membebani sistem.
Pola Load Leveling berbasis antrean memberikan informasi lebih lanjut.
Olahpesan yang andal
Perantara pesan membantu memastikan bahwa pesan tidak hilang bahkan jika komunikasi gagal antara produsen dan konsumen. Produsen dapat mengirimkan pesan ke perantara pesan dan konsumen dapat mengambilnya kembali saat komunikasi terjalin kembali. Produsen tidak diblokir kecuali kehilangan konektivitas dengan perantara pesan.
Pesan tangguh
Perantara pesan dapat menambahkan ketahanan kepada konsumen di sistem Anda. Jika konsumen gagal saat memproses pesan, contoh lain dari konsumen dapat memproses pesan itu. Pemrosesan ulang dapat dilakukan karena pesan tetap ada di perantara.
Pilihan teknologi untuk perantara pesan
Azure menyediakan beberapa layanan perantara pesan, masing-masing dengan berbagai fitur. Sebelum memilih layanan, tentukan niat dan persyaratan pesan.
Azure Service Bus Messaging
Antrean Olahpesan Azure Bus Layanan sangat cocok untuk mentransfer perintah dari produsen ke konsumen. Berikut adalah beberapa pertimbangan.
Model penarikan
Seorang konsumen antrean Azure Service Bus terus-menerus melakukan polling Azure Service Bus untuk memeriksa apakah pesan baru tersedia. SDK klien dan Pemicu Azure Functions untuk Azure Service Bus mengabstraksi model tersebut. Ketika pesan baru tersedia, panggilan balik konsumen dipanggil dan pesan dikirim ke konsumen.
Pengiriman terjamin
Azure Service Bus memungkinkan konsumen untuk mengintip antrean dan mengunci pesan dari konsumen lain.
Konsumen bertanggung jawab untuk melaporkan status pemrosesan pesan. Hanya ketika konsumen menandai pesan seperti yang digunakan Bus Layanan menghapus pesan dari antrean. Jika terjadi kegagalan, waktu habis, atau crash, Azure Service Bus membuka pesan sehingga konsumen lain dapat mengambilnya. Dengan cara ini, pesan tidak hilang dalam transfer.
Seorang produsen mungkin secara tidak sengaja mengirim pesan yang sama dua kali. Misalnya, instans produsen gagal setelah mengirim pesan. Produsen lain mengganti instans asli dan mengirim pesan lagi. Antrean Azure Service Bus menyediakan kemampuan de-duping bawaan yang mendeteksi dan menghapus pesan duplikat. Masih ada kemungkinan pesan terkirim dua kali. Misalnya, jika konsumen gagal saat memproses, pesan dikembalikan ke antrean dan diambil oleh konsumen yang sama atau konsumen yang lain. Logika pemrosesan pesan di konsumen harus idempoten sehingga bahkan jika pekerjaan diulang, status sistem tidak diubah.
Pemesanan pesan
Jika Anda ingin konsumen mendapatkan pesan sesuai urutan pengirimannya, antrean Bus Layanan menjamin pengiriman pertama kali (FIFO) yang dipesan dengan menggunakan sesi. Sesi dapat memiliki satu atau beberapa pesan. Pesan tersebut berkorelasi dengan properti SessionId. Pesan yang merupakan bagian dari sesi, tidak pernah kedaluwarsa. Sesi dapat dikunci ke konsumen untuk mencegah pesannya ditangani oleh konsumen yang berbeda.
Untuk informasi selengkapnya, lihat Sesi pesan.
Persistensi pesan
Antrean Service bus mendukung pemisahan temporal. Bahkan saat konsumen tidak tersedia atau tidak dapat memproses pesan, pesan tetap berada dalam antrean.
Titik pemeriksaan transaksi jangka panjang
Transaksi bisnis dapat berjalan dalam waktu yang lama. Setiap operasi dalam transaksi dapat memiliki beberapa pesan. Gunakan titik pemeriksaan untuk mengoordinasikan alur kerja dan memberikan ketahanan jika transaksi gagal.
Antrean Azure Service Bus memungkinkan pemeriksaan melalui kemampuan status sesi. Informasi status direkam secara bertahap dalam antrean (SetState) untuk pesan yang termasuk dalam suatu sesi. Misalnya, konsumen dapat melacak kemajuan dengan memeriksa status (GetState) sesekali. Jika konsumen gagal, konsumen lain dapat menggunakan informasi status untuk menentukan titik pemeriksaan terakhir yang diketahui untuk melanjutkan sesi.
Antrean surat gagal (DLQ)
Antrean Azure Service Bus memiliki subantrean default, yang disebut antrean surat gagal (DLQ) untuk menampung pesan yang tidak dapat dikirim atau diproses. Azure Service Bus atau logika pemrosesan pesan di konsumen dapat menambahkan pesan ke DLQ. DLQ menyimpan pesan hingga diambil dari antrean.
Berikut adalah contoh kapan pesan akhirnya dapat berada di DLQ:
Pesan racun adalah pesan yang tidak dapat ditangani karena salah bentuk atau berisi informasi tak terduga. Dalam antrean Azure Service Bus, Anda dapat mendeteksi pesan racun dengan mengatur properti MaxDeliveryCount dari antrean. Jika berapa kali pesan yang sama diterima melebihi nilai properti tersebut, Bus Layanan memindahkan pesan ke DLQ.
Sebuah pesan mungkin tidak lagi relevan jika tidak diproses dalam suatu periode. Antrean Azure Service Bus memungkinkan produsen untuk mengirim pesan dengan atribut time-to-live. Jika periode ini berakhir sebelum pesan diterima, pesan ditempatkan di DLQ.
Periksa pesan di DLQ untuk menentukan alasan kegagalan.
Solusi hibrida
Azure Service Bus menjembatani sistem lokal dan solusi cloud. Sistem lokal seringkali sulit dijangkau karena pembatasan firewall. Baik produsen maupun konsumen (bisa di lingkungan lokal atau di cloud) dapat menggunakan titik akhir antrean Azure Service Bus sebagai lokasi pengambilan dan pengantaran pesan.
Pola Jembatan Olahpesan adalah cara lain untuk menangani skenario ini.
Topik dan langganan
Azure Service Bus mendukung pola Penerbit-Pelanggan melalui topik dan langganan Azure Service Bus.
Fitur ini menyediakan cara bagi produsen untuk menyiarkan pesan ke banyak konsumen. Ketika sebuah topik menerima pesan, pesan itu diteruskan ke semua konsumen yang berlangganan. Sebagai opsi, langganan dapat memiliki kriteria filter yang memungkinkan konsumen mendapatkan subset pesan. Setiap konsumen mengambil pesan dari langganan dengan cara yang mirip dengan antrean.
Untuk informasi selengkapnya, lihat topik Azure Service Bus.
Kisi Aktivitas Azure
Kami merekomendasikan Azure Event Grid untuk peristiwa diskrit. Event Grid mengikuti pola Penerbit-Pelanggan. Saat sumber peristiwa memicu peristiwa, peristiwa tersebut diterbitkan ke topik Event Grid. Konsumen peristiwa tersebut membuat langganan Event Grid dengan menentukan jenis peristiwa dan penanganan aktivitas yang akan memproses peristiwa tersebut. Jika tidak ada pelanggan, peristiwa akan dibuang. Setiap peristiwa dapat memiliki beberapa langganan.
Model Push
Event Grid menyebarkan pesan ke pelanggan dalam model push. Misalkan Anda memiliki langganan Event Grid dengan webhook. Saat peristiwa baru tiba, Event Grid memposting peristiwa ke titik akhir webhook.
Terintegrasi dengan Azure
Pilih Event Grid jika Anda ingin mendapatkan pemberitahuan tentang sumber daya Azure. Banyak layanan Azure bertindak sebagai sumber peristiwa yang memiliki topik Event Grid bawaan. Event Grid juga mendukung berbagai layanan Azure yang dapat dikonfigurasi sebagai penanganan aktivitas. Sangat mudah untuk berlangganan topik tersebut untuk mengarahkan peristiwa ke penanganan aktivitas pilihan Anda. Misalnya, Anda dapat menggunakan Event Grid untuk menjalankan Azure Function saat penyimpanan blob dibuat atau dihapus.
Topik kustom
Buat topik Event Grid kustom jika Anda ingin mengirim peristiwa dari aplikasi atau layanan Azure yang tidak terintegrasi dengan Event Grid.
Misalnya, untuk melihat kemajuan seluruh transaksi bisnis, Anda ingin layanan yang berpartisipasi menaikkan peristiwa saat mereka memproses operasi bisnis individual mereka. Aplikasi web menampilkan peristiwa tersebut. Salah satu cara untuk menyelesaikan tugas ini adalah dengan membuat topik kustom dan menambahkan langganan dengan aplikasi web Anda yang terdaftar melalui HTTP WebHook. Saat layanan bisnis mengirim peristiwa ke topik kustom, Event Grid mendorongnya ke aplikasi web Anda.
Peristiwa yang difilter
Anda dapat menentukan filter dalam langganan untuk menginstruksikan Event Grid agar hanya merutekan sebagian peristiwa ke penanganan aktivitas tertentu. Anda menentukan filter dalam skema langganan. Setiap peristiwa yang dikirim ke topik dengan nilai yang cocok dengan filter akan otomatis diteruskan ke langganan tersebut.
Misalnya, konten dalam berbagai format diunggah ke Blob Storage. Setiap kali sebuah file ditambahkan, sebuah peristiwa dimunculkan dan dipublikasikan ke Event Grid. Langganan acara mungkin memiliki filter yang hanya mengirim peristiwa untuk gambar sehingga penanganan aktivitas dapat membuat gambar mini.
Untuk informasi selengkapnya tentang pemfilteran, lihat Memfilter peristiwa untuk Event Grid.
Throughput tinggi
Event Grid dapat merutekan 10.000.000 peristiwa per detik per wilayah. 100.000 operasi pertama per bulan gratis. Untuk pertimbangan biaya, lihat Berapa biaya Event Grid?
Pengiriman tangguh
Meskipun pengiriman yang sukses untuk peristiwa tidak sepenting perintah, Anda mungkin masih menginginkan beberapa jaminan tergantung jenis peristiwa. Event Grid menawarkan fitur yang dapat Anda aktifkan dan sesuaikan, seperti kebijakan coba lagi, waktu kedaluwarsa, dan surat gagal. Untuk informasi selengkapnya, lihat Pengiriman pesan Event Grid dan coba lagi.
Proses coba lagi Event Grid dapat membantu ketahanan tetapi tidak gagal-aman. Dalam proses coba lagi, Event Grid mungkin mengirimkan pesan lebih dari sekali, melewati, atau menunda beberapa percobaan ulang jika titik akhir tidak merespons untuk waktu yang lama. Untuk informasi selengkapnya, lihat Mencoba kembali jadwal.
Anda dapat mempertahankan peristiwa yang tidak terkirim ke akun penyimpanan blob dengan mengaktifkan surat gagal. Ada penundaan dalam pengiriman pesan ke titik akhir penyimpanan blob dan jika titik akhir itu tidak responsif, Event Grid akan membuang peristiwa tersebut. Untuk informasi selengkapnya, lihat Mengatur lokasi surat mati dan kebijakan percobaan kembali.
Azure Event Hubs
Saat Anda bekerja dengan aliran peristiwa, Azure Event Hubs adalah broker pesan yang direkomendasikan. Pada dasarnya, ini adalah buffer besar yang mampu menerima data dalam jumlah besar dengan latensi rendah. Data yang diterima dapat dibaca dengan cepat melalui operasi bersamaan. Anda dapat mengubah data yang diterima dengan menggunakan penyedia analitik real time. Azure Event Hubs juga menyediakan kemampuan untuk menyimpan peristiwa di akun penyimpanan.
Penyerapan cepat
Azure Event Hubs mampu menyerap jutaan peristiwa per detik. Peristiwa hanya ditambahkan ke aliran dan diurutkan berdasarkan waktu.
Model penarikan
Seperti Azure Event Grid, Azure Event Hubs juga menawarkan kemampuan Penerbit-Pelanggan. Perbedaan utama antara Azure Event Grid dan Azure Event Hubs adalah cara data peristiwa tersedia bagi pelanggan. Event Grid mendorong data yang diserap ke pelanggan sedangkan Azure Event Hubs membuat data tersedia dalam model penarikan. Saat peristiwa diterima, Azure Event Hubs menambahkannya ke aliran. Pelanggan mengelola kursornya dan dapat bergerak maju dan mundur dalam aliran, memilih waktu yang diimbangi, dan memutar ulang urutan sesuai kecepatannya.
Pemroses aliran adalah pelanggan yang menarik data dari Azure Event Hubs untuk tujuan transformasi dan analisis statistik. Gunakan Azure Stream Analytics dan Apache Spark untuk pemrosesan kompleks seperti agregasi dari rentang waktu atau deteksi anomali.
Jika Anda ingin bertindak pada setiap peristiwa per partisi, Anda dapat menarik data dengan menggunakan host prosesor Peristiwa, atau dengan menggunakan konektor bawaan seperti Azure Logic Apps untuk menyediakan logika transformasi. Opsi lain adalah menggunakan Azure Functions.
Partisi
Partisi adalah bagian dari aliran peristiwa. Peristiwa dibagi menggunakan kunci partisi. Misalnya, beberapa perangkat IoT mengirim data perangkat ke hub peristiwa. Kunci partisi adalah pengidentifikasi perangkat. Saat peristiwa diserap, Azure Event Hubs memindahkannya ke partisi yang terpisah. Dalam setiap partisi, semua acara diurutkan berdasarkan waktu.
Konsumen adalah instans kode yang memproses data peristiwa. Azure Event Hubs mengikuti pola konsumen yang dipartisi. Setiap konsumen hanya membaca partisi tertentu. Memiliki banyak partisi menghasilkan pemrosesan yang lebih cepat karena aliran dapat dibaca secara bersamaan oleh banyak konsumen.
Instans konsumen yang sama membentuk satu grup konsumen. Beberapa grup konsumen dapat membaca aliran yang sama dengan niat yang berbeda. Misalkan aliran peristiwa memiliki data dari sensor suhu. Satu grup konsumen dapat membaca aliran untuk mendeteksi anomali seperti lonjakan suhu. Konsumen lain dapat membaca aliran yang sama untuk menghitung suhu rata-rata bergulir di jendela temporal.
Azure Event Hubs mendukung pola Penerbit-Pelanggan dengan mengizinkan beberapa grup konsumen. Setiap grup konsumen adalah pelanggan.
Untuk informasi selengkapnya tentang partisi Azure Event Hubs, lihat Partisi.
Pengambilan Azure Event Hubs
Fitur Pengambilan memungkinkan Anda menyimpan aliran peristiwa ke penyimpanan Azure Blob atau Data Lake Storage. Cara menyimpan peristiwa ini dapat diandalkan karena meskipun akun penyimpanan tidak tersedia, Capture menyimpan data Anda selama satu periode, lalu menulis ke penyimpanan setelah tersedia.
Layanan Storage juga dapat menawarkan fitur tambahan untuk menganalisis peristiwa. Misalnya, dengan memanfaatkan tingkat akses dari akun penyimpanan blob, Anda dapat menyimpan peristiwa di tingkat yang lebih tinggi untuk data yang membutuhkan akses yang sering. Anda dapat menggunakan data tersebut untuk visualisasi. Sebagai alternatif, Anda dapat menyimpan data di tingkat arsip dan mengambilnya sesekali untuk tujuan audit.
Tangkap menyimpan semua peristiwa yang diserap oleh Azure Event Hubs dan berguna untuk pemrosesan batch. Anda dapat membuat laporan tentang data menggunakan fungsi MapReduce. Data yang diambil juga dapat berfungsi sebagai sumber kebenaran. Jika fakta tertentu terlewatkan saat menggabungkan data, Anda dapat merujuk ke data yang diambil.
Untuk detail tentang fitur ini, lihat Mengambil peristiwa melalui Azure Event Hubs di Azure Blob Storage atau Azure Data Lake Storage.
Dukungan untuk klien Apache Kafka
Azure Event Hubs menyediakan titik akhir untuk klien Apache Kafka. Klien yang sudah ada dapat memperbarui konfigurasi mereka untuk menunjuk ke titik akhir dan mulai mengirim peristiwa ke Azure Event Hubs. Anda tidak perlu membuat perubahan kode apa pun.
Untuk informasi selengkapnya, lihat Azure Event Hubs for Apache Kafka.
Skenario crossover
Dalam beberapa kasus, menggabungkan dua layanan olahpesan merupakan hal yang menguntungkan.
Menggabungkan layanan tersebut dapat meningkatkan efisiensi sistem olahpesan Anda. Misalnya, dalam transaksi bisnis Anda, Anda menggunakan antrean Azure Service Bus untuk menangani pesan. Antrean yang sebagian besar menganggur dan menerima pesan terkadang tidak efisien, karena konsumen terus-menerus melakukan polling antrean untuk pesan baru. Anda dapat menyiapkan langganan Event Grid dengan Azure Function sebagai penanganan aktivitas. Setiap kali antrean menerima pesan dan tidak ada konsumen yang mendengarkan, Event Grid mengirimkan pemberitahuan, yang memanggil Azure Function yang mengalirkan antrean.
Untuk detail tentang menyambungkan Azure Service Bus ke Event Grid, lihat Ringkasan integrasi Azure Service Bus ke Event Grid.
Integrasi Enterprise menggunakan antrean pesan dan arsitektur referensi peristiwa menunjukkan implementasi Bus Layanan ke integrasi Event Grid.
Berikut adalah contoh lain: Event Grid menerima serangkaian peristiwa di mana beberapa peristiwa memerlukan alur kerja sementara yang lain untuk pemberitahuan. Metadata pesan menunjukkan jenis peristiwa. Salah satu cara untuk membedakan adalah dengan memeriksa metadata dengan menggunakan fitur pemfilteran dalam langganan peristiwa. Jika memerlukan alur kerja, Event Grid mengirimkannya ke antrean Azure Service Bus. Penerima antrean itu dapat mengambil tindakan yang diperlukan. Peristiwa pemberitahuan dikirim ke Logic Apps untuk mengirim email peringatan.
Pola terkait
Pertimbangkan pola berikut saat menerapkan pesan asinkron:
- Pola Konsumen yang Bersaing. Beberapa konsumen mungkin perlu bersaing untuk membaca pesan dari antrean. Pola ini menjelaskan cara memproses beberapa pesan secara bersamaan untuk mengoptimalkan throughput, meningkatkan skalabilitas dan ketersediaan, serta menyeimbangkan beban kerja.
- Pola Antrean Prioritas. Untuk kasus di mana logika bisnis mengharuskan beberapa pesan diproses sebelum pesan lain, pola ini menjelaskan bagaimana pesan yang diposting oleh produsen dengan prioritas yang lebih tinggi diterima dan diproses lebih cepat oleh konsumen daripada pesan dengan prioritas yang lebih rendah.
- Pola Pemerataan Beban Berdasarkan Antrean. Pola ini menggunakan perantara pesan untuk bertindak sebagai buffer antara produsen dan konsumen untuk membantu meminimalkan dampak pada ketersediaan dan responsivitas beban berat yang terputus-putus untuk kedua entitas tersebut.
- Pola percobaan ulang. Produsen atau konsumen mungkin tidak dapat terhubung ke antrean, tetapi alasan kegagalan ini mungkin bersifat sementara dan cepat berlalu. Pola ini menjelaskan cara menangani situasi ini untuk menambahkan ketahanan ke aplikasi.
- Pola Pengawas Agen Penjadwal. Olahpesan sering digunakan sebagai bagian dari penerapan alur kerja. Pola ini menunjukkan bagaimana pesan dapat mengoordinasikan serangkaian tindakan di seluruh rangkaian layanan terdistribusi dan sumber daya jarak jauh lainnya, dan memungkinkan sistem untuk memulihkan dan mencoba kembali tindakan yang gagal.
- Pola koreografi. Pola ini menunjukkan bagaimana layanan dapat menggunakan olahpesan untuk mengontrol alur kerja transaksi bisnis.
- Pola Claim-Check. Pola ini menunjukkan cara membagi pesan besar menjadi pemeriksaan klaim dan payload.
Sumber daya komunitas
Postingan blog Jonathon Oliver: Idempotensi
Postingan blog Martin Fowler: Apa yang Anda maksud dengan "Berbasis Peristiwa"?