Publisher-Subscriber pattern

Kisi Aktivitas Azure

Pusat Aktivitas Azure

Azure Service Bus

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

Also called: Pub/sub messaging

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?

Solution

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. The sender in this pattern is also called the publisher.

  Note

  A message is a packet of data. An event is a message that notifies other components about a change or an action that has taken place.

• Satu saluran pesan output per konsumen. The consumers are known as subscribers.

• 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:

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

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

• Security. 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:

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

• Wildcard subscribers. Pertimbangkan untuk mengizinkan pelanggan berlangganan beberapa topik melalui wildcard.

• Bi-directional communication. Saluran dalam sistem terbitkan-berlangganan diperlakukan sebagai satu arah. If a specific subscriber needs to send acknowledgment or communicate status back to the publisher, consider using the Request/Reply Pattern. Pola ini menggunakan satu saluran untuk mengirim pesan ke pelanggan, dan saluran balasan terpisah untuk berkomunikasi kembali ke penerbit.

• Message ordering. 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.

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

• Poison messages. 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.

• Repeated messages. 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.

• Message expiration. 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.

• Message scheduling. 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.

Workload design

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. For example:

Pillar	Bagaimana pola ini mendukung tujuan pilar
Reliability design decisions help your workload become resilient to malfunction and to ensure that it recovers to a fully functioning state after a failure occurs.	Pemisahan yang diperkenalkan dalam pola ini memungkinkan target keandalan independen pada komponen dan menghapus dependensi langsung. - Analisis mode kegagalan RE:03 - Pekerjaan latar belakang RE:07
Security design decisions help ensure the confidentiality, integrity, and availability of your workload's data and systems.	Pola ini memperkenalkan batas segmentasi keamanan penting yang memungkinkan pelanggan antrean terisolasi jaringan dari penerbit. - SE:04 Segmentation
Cost Optimization is focused on sustaining and improving your workload's return on investment.	Desain yang dipisahkan ini dapat memungkinkan pendekatan berbasis peristiwa dalam arsitektur Anda, yang cocok dengan penagihan berbasis konsumsi untuk menghindari provisi berlebih. - Pengoptimalan LAJU CO:05 - Biaya penskalan CO:12
Operational Excellence helps deliver workload quality through standardized processes and team cohesion.	Lapisan tidak langsung ini dapat memungkinkan Anda mengubah implementasi dengan aman di sisi penerbit atau pelanggan tanpa perlu mengoordinasikan perubahan pada kedua komponen. - Pengembangan beban kerja OE:06 - Praktik penyebaran OE:11 Aman
Performance Efficiency helps your workload efficiently meet demands through optimizations in scaling, data, code.	Pemisahan penerbit dari konsumen memungkinkan Anda mengoptimalkan komputasi dan kode khusus untuk tugas yang perlu dilakukan konsumen untuk pesan tertentu. - Perencanaan kapasitas PE:02 - PE:05 Penskalaan dan pemartisian

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

Example

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.

Next steps

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:

• Observer pattern. 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.

Related resources

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

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

Also called: Pub/sub messaging

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?

Solution

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. The sender in this pattern is also called the publisher.

  Note

  A message is a packet of data. An event is a message that notifies other components about a change or an action that has taken place.

• Satu saluran pesan output per konsumen. The consumers are known as subscribers.

• 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:

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

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

• Security. 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:

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

• Wildcard subscribers. Pertimbangkan untuk mengizinkan pelanggan berlangganan beberapa topik melalui wildcard.

• Bi-directional communication. Saluran dalam sistem terbitkan-berlangganan diperlakukan sebagai satu arah. If a specific subscriber needs to send acknowledgment or communicate status back to the publisher, consider using the Request/Reply Pattern. Pola ini menggunakan satu saluran untuk mengirim pesan ke pelanggan, dan saluran balasan terpisah untuk berkomunikasi kembali ke penerbit.

• Message ordering. 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.

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

• Poison messages. 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.

• Repeated messages. 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.

• Message expiration. 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.

• Message scheduling. 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.

Workload design

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. For example:

Pillar	Bagaimana pola ini mendukung tujuan pilar
Reliability design decisions help your workload become resilient to malfunction and to ensure that it recovers to a fully functioning state after a failure occurs.	Pemisahan yang diperkenalkan dalam pola ini memungkinkan target keandalan independen pada komponen dan menghapus dependensi langsung. - Analisis mode kegagalan RE:03 - Pekerjaan latar belakang RE:07
Security design decisions help ensure the confidentiality, integrity, and availability of your workload's data and systems.	Pola ini memperkenalkan batas segmentasi keamanan penting yang memungkinkan pelanggan antrean terisolasi jaringan dari penerbit. - SE:04 Segmentation
Cost Optimization is focused on sustaining and improving your workload's return on investment.	Desain yang dipisahkan ini dapat memungkinkan pendekatan berbasis peristiwa dalam arsitektur Anda, yang cocok dengan penagihan berbasis konsumsi untuk menghindari provisi berlebih. - Pengoptimalan LAJU CO:05 - Biaya penskalan CO:12
Operational Excellence helps deliver workload quality through standardized processes and team cohesion.	Lapisan tidak langsung ini dapat memungkinkan Anda mengubah implementasi dengan aman di sisi penerbit atau pelanggan tanpa perlu mengoordinasikan perubahan pada kedua komponen. - Pengembangan beban kerja OE:06 - Praktik penyebaran OE:11 Aman
Performance Efficiency helps your workload efficiently meet demands through optimizations in scaling, data, code.	Pemisahan penerbit dari konsumen memungkinkan Anda mengoptimalkan komputasi dan kode khusus untuk tugas yang perlu dilakukan konsumen untuk pesan tertentu. - Perencanaan kapasitas PE:02 - PE:05 Penskalaan dan pemartisian

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

Example

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.

Next steps

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:

• Observer pattern. 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.

Related resources

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