Pola Penerbit-Pelanggan

Aktifkan aplikasi untuk mengumumkan acara ke beberapa konsumen yang tertarik secara asinkron, tanpa menghubungkan pengirim ke penerima.

Disebut juga: Olahpesan pub/sub

Konteks dan masalah

Dalam aplikasi berbasis cloud dan terdistribusi, komponen sistem sering kali perlu memberikan informasi ke komponen lain saat peristiwa terjadi.

Pesan asinkron adalah cara yang efektif untuk memisahkan pengirim dari konsumen, dan menghindari pemblokiran pengirim untuk menunggu respons. Namun, menggunakan antrian pesan khusus untuk setiap konsumen tidak menskalakan secara efektif ke banyak konsumen. Sebagai tambahan, beberapa konsumen mungkin hanya tertarik pada sebagian informasi. Bagaimana pengirim mengumumkan acara kepada semua konsumen yang tertarik tanpa mengetahui identitas mereka?

Solusi

Memperkenalkan subsistem olahpesan asinkron yang mencakup hal berikut:

• Saluran pesan input yang digunakan oleh pengirim. Pengirim mengemas peristiwa ke dalam pesan, menggunakan format pesan yang diketahui, dan mengirimkan pesan-pesan ini melalui saluran input. Pengirim dalam pola ini juga disebut penerbit.

  Catatan

  Pesan adalah paket data. Peristiwa adalah pesan yang memberi tahu komponen lain tentang perubahan atau tindakan yang telah terjadi.

• Satu saluran pesan output per konsumen. Konsumen dikenal sebagai pelanggan.

• Mekanisme untuk menyalin setiap pesan dari saluran input ke saluran output untuk semua pelanggan yang tertarik dengan pesan itu. Operasi ini biasanya ditangani oleh perantara seperti perantara pesan atau bus acara.

Diagram berikut menunjukkan komponen logis dari pola ini:

Olahpesan pub/sub memiliki manfaat sebagai berikut:

• Fitur ini memisahkan subsistem yang masih perlu berkomunikasi. Subsistem dapat dikelola secara independen, dan pesan dapat dikelola dengan baik bahkan jika satu atau lebih penerima sedang offline.

• Fitur ini meningkatkan skalabilitas dan meningkatkan daya tanggap pengirim. Pengirim dapat dengan cepat mengirim satu pesan ke saluran input, lalu kembali ke tanggung jawab pemrosesan intinya. Infrastruktur olahpesan bertanggung jawab untuk memastikan pesan terkirim ke pelanggan yang tertarik.

• Solusi ini meningkatkan keandalan. Olahpesan asinkron membantu aplikasi terus berjalan dengan lancar di bawah beban yang meningkat dan menangani kegagalan yang terputus-putus dengan lebih efektif.

• Fitur ini memungkinkan pemrosesan yang ditangguhkan atau dijadwalkan. Pelanggan dapat menunggu untuk menerima pesan hingga jam sibuk, atau pesan dapat dialihkan atau diproses sesuai dengan jadwal tertentu.

• Fitur ini memungkinkan integrasi yang lebih sederhana antara sistem yang menggunakan platform, bahasa pemrograman, atau protokol komunikasi yang berbeda, serta antara sistem lokal dan aplikasi yang berjalan di cloud.

• Fitur ini memfasilitasi alur kerja asinkron di seluruh perusahaan.

• Fitur ini meningkatkan kemampuan pengujian. Saluran dapat dipantau dan pesan dapat diperiksa atau dicatat sebagai bagian dari strategi pengujian integrasi secara keseluruhan.

• Fitur ini memberikan pemisahan kekhawatiran untuk aplikasi Anda. Setiap aplikasi dapat berfokus pada kemampuan intinya, sementara infrastruktur olahpesan menangani semua yang diperlukan untuk merutekan pesan ke banyak konsumen dengan andal.

Masalah dan pertimbangan

Pertimbangkan poin-poin berikut saat memutuskan cara menerapkan pola ini:

• Teknologi yang ada. Sangat direkomendasikan untuk menggunakan produk dan layanan olahpesan yang tersedia yang mendukung model terbitkan-berlangganan, daripada membangun model Anda sendiri. Di Azure, pertimbangkan untuk menggunakan Service Bus, Event Hubs atau Event Grid. Teknologi lain yang dapat digunakan untuk olahpesan pub/sub termasuk Redis, RabbitMQ, dan Apache Kafka.

• Penanganan langganan. Infrastruktur pengiriman pesan harus menyediakan mekanisme yang dapat digunakan konsumen untuk berlangganan atau berhenti berlangganan dari saluran yang tersedia.

• Keamanan. Menghubungkan ke saluran pesan apa pun harus dibatasi oleh kebijakan keamanan untuk mencegah penyadapan oleh pengguna atau aplikasi yang tidak sah.

• Subset pesan. Pelanggan biasanya hanya tertarik pada subset dari pesan yang didistribusikan oleh penerbit. Layanan pesan sering memungkinkan pelanggan untuk mempersempit kumpulan pesan yang diterima oleh:

  • Topik. Setiap topik memiliki saluran keluaran khusus, dan setiap konsumen dapat berlangganan semua topik yang relevan.
  • Pemfilteran konten. Pesan diperiksa dan didistribusikan berdasarkan konten setiap pesan. Setiap pelanggan dapat menentukan konten yang diminatinya.

• Pelanggan wildcard. Pertimbangkan untuk mengizinkan pelanggan berlangganan beberapa topik melalui wildcard.

• Komunikasi dua arah. Saluran dalam sistem terbitkan-berlangganan diperlakukan sebagai satu arah. Jika pelanggan tertentu perlu mengirim pengakuan atau mengomunikasikan status kembali ke penerbit, pertimbangkan untuk menggunakan Pola Minta/Balas. Pola ini menggunakan satu saluran untuk mengirim pesan ke pelanggan, dan saluran balasan terpisah untuk berkomunikasi kembali ke penerbit.

• Pengurutan pesan. Urutan saat instans konsumen menerima pesan tidak dijamin, dan tidak selalu mencerminkan urutan pembuatan pesan. Rancang sistem untuk memastikan bahwa pemrosesan pesan idempoten untuk membantu menghilangkan ketergantungan pada urutan penanganan pesan.

• Prioritas pesan. Beberapa solusi mungkin mengharuskan pesan diproses dalam urutan tertentu. Pola Antrean Prioritas menyediakan mekanisme untuk memastikan pesan tertentu terkirim sebelum pesan lainnya.

• Pesan racun. Pesan yang salah format, atau tugas yang memerlukan akses ke sumber daya yang tidak tersedia, dapat menyebabkan instans layanan gagal beroperasi. Sistem harus mencegah pesan tersebut dikembalikan ke antrean. Sebaliknya, tangkap dan simpan detail pesan ini di tempat lain sehingga dapat dianalisis jika perlu. Beberapa broker pesan, seperti Azure Bus Layanan, mendukung ini melalui fungsionalitas antrean surat mati mereka.

• Pesan berulang. Pesan yang sama mungkin dikirim lebih dari sekali. Misalnya, pengirim mungkin gagal setelah memposting pesan. Kemudian contoh baru pengirim mungkin memulai dan mengulangi pesannya. Infrastruktur olahpesan harus menerapkan deteksi dan penghapusan pesan duplikat (juga dikenal sebagai de-duping) berdasarkan ID pesan untuk menyediakan pengiriman pesan paling banyak satu kali. Atau, jika menggunakan infrastruktur olahpesan yang tidak men-de-duplikat pesan, pastikan logika pemrosesan pesan idempotensi.

• Waktu kedaluwarsa pesan. Sebuah pesan mungkin memiliki masa pakai yang terbatas. Jika tidak diproses dalam periode ini, mungkin tidak lagi relevan dan harus dibuang. Pengirim dapat menentukan waktu kedaluwarsa sebagai bagian dari data dalam pesan. Penerima dapat memeriksa informasi ini sebelum memutuskan apakah akan menjalankan logika bisnis yang terkait dengan pesan.

• Penjadwalan pesan. Sebuah pesan mungkin diembargo sementara dan tidak boleh diproses hingga tanggal dan waktu tertentu. Pesan tidak boleh tersedia untuk penerima sampai saat ini.

• Menskalakan pelanggan. Jika pelanggan tertentu tidak dapat mengikuti tingkat pesan yang diterimanya, gunakan pola Konsumen Yang Bersaing untuk menskalakannya.

Kapan menggunakan pola ini

Gunakan pola ini ketika:

• Sebuah aplikasi perlu menyiarkan informasi ke sejumlah besar konsumen.

• Aplikasi perlu berkomunikasi dengan satu atau beberapa aplikasi atau layanan yang dikembangkan secara independen, yang dapat menggunakan platform, bahasa pemrograman, dan protokol komunikasi yang berbeda.

• Sebuah aplikasi dapat mengirimkan informasi kepada konsumen tanpa memerlukan respons real-time dari konsumen.

• Sistem yang terintegrasi dirancang untuk mendukung model konsistensi akhir untuk data mereka.

• Aplikasi perlu mengomunikasikan informasi ke banyak konsumen, yang mungkin memiliki persyaratan ketersediaan atau jadwal waktu aktif yang berbeda dari pengirim.

Pola ini mungkin tidak berguna jika:

• Sebuah aplikasi hanya memiliki sedikit konsumen yang membutuhkan informasi yang sangat berbeda dari aplikasi yang memproduksi.

• Sebuah aplikasi membutuhkan interaksi hampir real-time dengan konsumen.

Desain beban kerja

Arsitek harus mengevaluasi bagaimana pola Penerbit/Pelanggan dapat digunakan dalam desain beban kerja mereka untuk mengatasi tujuan dan prinsip yang tercakup dalam pilar Azure Well-Architected Framework. Contohnya:

Seperti halnya keputusan desain apa pun, pertimbangkan tradeoff terhadap tujuan pilar lain yang mungkin diperkenalkan dengan pola ini.

Contoh

Diagram berikut menunjukkan arsitektur integrasi perusahaan yang menggunakan Service Bus untuk mengoordinasikan alur kerja, dan Event Grid untuk memberi tahu subsistem tentang peristiwa yang terjadi. Untuk informasi selengkapnya, lihat Integrasi perusahaan di Azure menggunakan antrean dan peristiwa pesan.

Langkah berikutnya

Panduan berikut bisa jadi relevan saat menerapkan pola berikut ini:

• Pilih antara layanan Azure yang mengirimkan pesan.

• Primer Olahpesan Asinkron. Antrean pesan adalah mekanisme komunikasi yang asinkron. Jika layanan konsumen perlu mengirim balasan ke aplikasi, mungkin perlu mengimplementasikan suatu bentuk pesan respons. Primer Olahpesan Asinkron memberikan informasi tentang cara mengimplementasikan pesan permintaan/balasan menggunakan antrean pesan.

Pola berikut mungkin relevan saat menerapkan pola ini:

• Pola pengamat. Pola Terbitkan-Berlangganan dibangun di atas pola Pengamat dengan memisahkan subjek dari pengamat melalui pesan asinkron.

• Pola Perantara Pesan. Banyak subsistem olahpesan yang mendukung model terbitkan-berlangganan diimplementasikan melalui perantara pesan.

Posting blog ini menjelaskan berbagai cara menangani pesan yang tidak berurutan.

Sumber daya terkait

• Gaya arsitektur berdasarkan peristiwa adalah gaya arsitektur yang menggunakan olahpesan pub/sub.
• Pemrosesan pesan idempotensi
• Integrasi perusahaan di Azure menggunakan antrean dan peristiwa pesan