Gaya arsitektur berbasis peristiwa

Azure Stream Analytics

Azure Functions

Azure Service Bus

Arsitektur berbasis peristiwa terdiri dari produsen peristiwa yang menghasilkan aliran peristiwa, konsumen peristiwa yang mendengarkan peristiwa ini, dan saluran peristiwa yang mentransfer peristiwa dari produsen ke konsumen.

Peristiwa disampaikan hampir secara real time, sehingga konsumen dapat segera merespons peristiwa yang terjadi. Produsen dipisahkan dari konsumen: Produsen tidak tahu konsumen mana yang mendengarkan. Konsumen juga dipisahkan satu sama lain, dan setiap konsumen melihat semua peristiwa. Proses ini berbeda dari pola Konsumen yang Bersaing di mana konsumen menarik pesan dari antrean dan pesan hanya diproses satu kali, dengan asumsi bahwa tidak ada kesalahan. Dalam beberapa sistem, seperti Azure Internet of Things (IoT), peristiwa harus diserap pada volume tinggi.

Arsitektur berbasis peristiwa dapat menggunakan model terbitkan-berlangganan atau model aliran peristiwa.

• Pub/sub: Infrastruktur olahpesan terbitkan-berlangganan melacak langganan. Saat peristiwa diterbitkan, peristiwa tersebut akan dikirim ke setiap pelanggan. Peristiwa tidak dapat diputar ulang setelah diterima, dan pelanggan baru tidak melihat peristiwa tersebut.

• Streaming acara: Peristiwa ditulis ke log. Peristiwa diurutkan secara ketat dalam partisi dan tahan lama. Klien tidak berlangganan aliran. Sebagai gantinya, klien dapat membaca dari bagian mana pun dari aliran. Klien bertanggung jawab untuk memajukan posisi mereka di aliran. Itu berarti klien dapat bergabung kapan saja dan dapat memutar ulang peristiwa.

Di sisi konsumen, ada beberapa variasi umum:

• Pemrosesan peristiwa sederhana: Peristiwa segera memicu tindakan di konsumen. Misalnya, Anda dapat menggunakan Azure Functions dengan pemicu Azure Service Bus sehingga fungsi berjalan setiap kali pesan diterbitkan ke topik Bus Layanan.

• Korelasi peristiwa dasar: Konsumen memproses beberapa peristiwa bisnis diskrit, menghubungkannya dengan beberapa pengidentifikasi, dan mempertahankan informasi dari peristiwa sebelumnya untuk digunakan saat memproses peristiwa selanjutnya. Pustaka seperti NServiceBus dan MassTransit mendukung pola ini.

• Pemrosesan peristiwa yang kompleks: Konsumen menggunakan teknologi seperti Azure Stream Analytics untuk menganalisis serangkaian peristiwa dan mengidentifikasi pola dalam data peristiwa. Misalnya, Anda dapat mengagregasi pembacaan dari perangkat yang disematkan selama jendela waktu, dan menghasilkan pemberitahuan jika rata-rata pemindahan melewati ambang batas tertentu.

• Pemrosesan aliran peristiwa: Gunakan platform streaming data, seperti Azure IoT Hub atau Apache Kafka, sebagai alur untuk menyerap peristiwa dan mengumpankannya ke prosesor streaming. Prosesor aliran berfungsi untuk memproses atau mengubah aliran. Mungkin ada beberapa prosesor aliran untuk subsistem aplikasi yang berbeda. Pendekatan ini sangat cocok untuk beban kerja IoT.

Sumber peristiwa mungkin berada di luar sistem, seperti perangkat fisik dalam solusi IoT. Dalam hal ini, sistem harus dapat menyerap data pada volume dan throughput yang diperlukan sumber data.

Ada dua pendekatan utama untuk menyusun payload peristiwa. Ketika Anda memiliki kontrol atas konsumen peristiwa Anda, Anda dapat memutuskan struktur payload untuk setiap konsumen. Strategi ini memungkinkan Anda untuk mencampur pendekatan sesuai kebutuhan dalam satu beban kerja.

• Sertakan semua atribut yang diperlukan dalam payload: Gunakan pendekatan ini saat Anda ingin konsumen memiliki semua informasi yang tersedia tanpa perlu mengkueri sumber data eksternal. Namun, ini dapat menyebabkan masalah konsistensi data karena beberapa sistem rekaman, terutama setelah pembaruan. Manajemen kontrak dan penerapan versi juga dapat menjadi kompleks.

• Sertakan hanya kunci dalam payload: Dalam pendekatan ini, konsumen mengambil atribut yang diperlukan, seperti kunci primer, untuk mengambil data yang tersisa dari sumber data secara independen. Metode ini memberikan konsistensi data yang lebih baik karena memiliki satu sistem rekaman. Namun, ini dapat berkinerja lebih buruk daripada pendekatan pertama karena konsumen harus sering mengkueri sumber data. Anda memiliki lebih sedikit kekhawatiran mengenai kopling, bandwidth, manajemen kontrak, atau penerapan versi karena peristiwa yang lebih kecil dan kontrak yang lebih sederhana mengurangi kompleksitas.

Dalam diagram sebelumnya, setiap jenis konsumen ditampilkan sebagai satu kotak. Untuk menghindari konsumen menjadi satu titik kegagalan dalam sistem, biasanya memiliki beberapa instans konsumen. Beberapa instans mungkin juga diperlukan untuk menangani volume dan frekuensi peristiwa. Satu konsumen dapat memproses peristiwa pada beberapa utas. Penyiapan ini dapat menciptakan tantangan jika peristiwa harus diproses secara berurutan atau memerlukan semantik sekali persis. Untuk informasi selengkapnya, lihat Meminimalkan koordinasi.

Ada dua topologi utama dalam banyak arsitektur berbasis peristiwa:

• Topologi broker: Komponen menyiarkan kejadian sebagai peristiwa ke seluruh sistem. Komponen lain bertindak pada peristiwa atau mengabaikan peristiwa. Topologi ini berguna ketika alur pemrosesan peristiwa relatif sederhana. Tidak ada koordinasi atau orkestrasi pusat, sehingga topologi ini bisa dinamis. Topologi ini sangat dipisahkan, yang membantu memberikan skalabilitas, responsivitas, dan toleransi kesalahan komponen. Tidak ada komponen yang memiliki atau mengetahui status transaksi bisnis multistep apa pun, dan tindakan diambil secara asinkron. Selanjutnya, transaksi terdistribusi berisiko karena tidak ada cara asli untuk dimulai ulang atau diputar ulang. Anda perlu mempertimbangkan penanganan kesalahan dan strategi intervensi manual dengan cermat karena topologi ini dapat menjadi sumber inkonsistensi data.

• Topologi mediator: Topologi ini membahas beberapa kekurangan topologi broker. Ada mediator peristiwa yang mengelola dan mengontrol alur peristiwa. Mediator peristiwa mempertahankan status dan mengelola penanganan kesalahan dan memulai ulang kemampuan. Berbeda dengan topologi broker, dalam topologi ini, komponen menyiarkan kemunculan sebagai perintah dan hanya untuk saluran yang ditunjuk. Saluran ini biasanya merupakan antrean pesan. Konsumen diharapkan untuk memproses perintah ini. Topologi ini memberikan lebih banyak kontrol, penanganan kesalahan terdistribusi yang lebih baik, dan konsistensi data yang berpotensi lebih baik. Topologi ini memang memperkenalkan peningkatan kopling antar komponen, dan mediator peristiwa dapat menjadi hambatan atau kekhawatiran keandalan.

Kapan harus menggunakan arsitektur ini

Anda harus menggunakan arsitektur ini saat:

• Beberapa subsistem harus memproses peristiwa yang sama.
• Pemrosesan real time dengan jeda waktu minimum diperlukan.
• Pemrosesan peristiwa yang kompleks, seperti pencocokan pola atau agregasi dari jendela waktu ke waktu, diperlukan.
• Diperlukan volume tinggi dan kecepatan data yang tinggi, seperti, misalnya, IoT.

Keuntungan

Manfaat arsitektur ini adalah:

• Produsen dan konsumen dipisahkan.
• Tidak ada integrasi titik-ke-titik. Sangat mudah menambahkan konsumen baru ke sistem.
• Konsumen dapat segera menanggapi peristiwa saat terjadi.
• Sangat dapat diskalakan, elastis, dan terdistribusi.
• Subsistem memiliki tampilan independen aliran peristiwa.

Tantangan

• Pengiriman terjamin.

  Dalam beberapa sistem, terutama dalam skenario IoT, sangat penting untuk menjamin bahwa peristiwa disampaikan.

• Memproses peristiwa secara berurutan atau tepat sekali.

  Untuk ketahanan dan skalabilitas, setiap jenis konsumen biasanya berjalan dalam beberapa instans. Proses ini dapat menciptakan tantangan jika peristiwa harus diproses secara berurutan dalam jenis konsumen, atau jika logika pemrosesan pesan idempogen tidak diimplementasikan.

• Koordinasi pesan di seluruh layanan.

  Proses bisnis sering memiliki beberapa layanan yang menerbitkan dan berlangganan pesan untuk mencapai hasil yang konsisten di seluruh beban kerja. Anda dapat menggunakan pola alur kerja seperti pola Koreografi dan Orkestrasi Saga untuk mengelola alur pesan dengan andal di berbagai layanan.

• Penanganan kesalahan.

  Arsitektur berbasis peristiwa terutama menggunakan komunikasi asinkron. Tantangan dengan komunikasi asinkron adalah penanganan kesalahan. Salah satu cara untuk mengatasi masalah ini adalah dengan menggunakan prosesor penanganan kesalahan terpisah. Ketika konsumen peristiwa mengalami kesalahan, itu segera dan secara asinkron mengirim peristiwa yang salah ke prosesor penanganan kesalahan dan melanjutkan. Prosesor penanganan kesalahan mencoba memperbaiki kesalahan dan mengirim peristiwa kembali ke saluran penyerapan asli. Tetapi jika prosesor penanganan kesalahan gagal, prosesor dapat mengirim peristiwa yang salah ke administrator untuk pemeriksaan lebih lanjut. Jika Anda menggunakan prosesor penanganan kesalahan, peristiwa yang salah diproses dari urutan saat dikirim ulang.

• Kehilangan data.

  Tantangan lain dengan komunikasi asinkron adalah kehilangan data. Jika salah satu komponen mengalami crash sebelum berhasil memproses dan menyerahkan peristiwa ke komponen berikutnya, maka peristiwa dihilangkan dan tidak pernah masuk ke tujuan akhir. Untuk meminimalkan kemungkinan kehilangan data, pertahankan peristiwa dalam transit dan hapus atau hapus antrean peristiwa hanya ketika komponen berikutnya mengakui tanda terima peristiwa. Fitur-fitur ini dikenal sebagai mode pengakuan klien dan dukungan peserta terakhir.

• Implementasi pola respons permintaan tradisional.

  Terkadang produsen peristiwa memerlukan respons segera dari konsumen peristiwa, seperti mendapatkan kelayakan pelanggan sebelum melanjutkan pesanan. Dalam arsitektur berbasis peristiwa, komunikasi sinkron dapat dicapai dengan menggunakan pesan respons permintaan.

  Pola ini biasanya diimplementasikan dengan dua antrean: Antrean permintaan dan antrean respons. Produsen peristiwa mengirimkan permintaan asinkron ke antrean permintaan, menjeda operasi lain pada tugas tersebut, dan menunggu respons dalam antrean balasan. Pendekatan ini secara efektif mengubah pola ini menjadi proses yang sinkron. Konsumen peristiwa kemudian memproses permintaan dan mengirim balasan kembali melalui antrean respons. Pendekatan ini biasanya menggunakan ID sesi untuk pelacakan, sehingga produsen peristiwa mengetahui pesan mana dalam antrean respons yang terkait dengan permintaan tertentu. Permintaan asli juga dapat menentukan nama antrean respons, yang berpotensi sementara, dalam header balasan atau atribut kustom lain yang disepakati bersama.

• Pemeliharaan jumlah peristiwa yang sesuai.

  Menghasilkan sejumlah besar peristiwa halus dapat menjenuhkan dan membanjiri sistem, sehingga sulit untuk menganalisis alur keseluruhan peristiwa secara efektif. Masalah ini diperburuk ketika perubahan perlu digulung balik. Sebaliknya, peristiwa yang terlalu mengonsolidasikan juga dapat menciptakan masalah, yang mengakibatkan pemrosesan dan respons yang tidak perlu dari konsumen peristiwa.

  Untuk mencapai keseimbangan yang tepat, pertimbangkan konsekuensi peristiwa dan apakah konsumen perlu memeriksa payload peristiwa untuk menentukan respons mereka. Misalnya, jika Anda memiliki komponen pemeriksaan kepatuhan, mungkin cukup untuk menerbitkan hanya dua jenis peristiwa: sesuai dan tidak patuh. Pendekatan ini membantu memastikan bahwa hanya konsumen yang relevan yang memproses setiap peristiwa, yang mencegah pemrosesan yang tidak perlu.

Pertimbangan lain

• Jumlah data yang disertakan dalam suatu peristiwa dapat menjadi pertimbangan signifikan yang memengaruhi performa dan biaya. Anda dapat menyederhanakan kode pemrosesan dan menghilangkan pencarian tambahan dengan menempatkan semua informasi relevan yang diperlukan untuk diproses secara langsung dalam peristiwa tersebut. Saat Anda hanya menambahkan jumlah informasi minimal ke suatu peristiwa, seperti beberapa pengidentifikasi, Anda mengurangi waktu dan biaya transportasi. Namun, pendekatan ini memerlukan kode pemrosesan untuk mengambil informasi tambahan yang dibutuhkannya. Untuk informasi selengkapnya, lihat Menempatkan peristiwa Anda pada diet.

• Permintaan hanya terlihat oleh komponen penanganan permintaan. Tetapi peristiwa sering terlihat oleh beberapa komponen dalam beban kerja, bahkan jika komponen tersebut tidak atau tidak dimaksudkan untuk mengonsumsinya. Untuk beroperasi dengan pola pikir "asumsikan pelanggaran", perhatikan informasi apa yang Anda sertakan dalam peristiwa untuk mencegah paparan informasi yang tidak diinginkan.

• Banyak aplikasi menggunakan arsitektur berbasis peristiwa sebagai arsitektur utamanya. Anda dapat menggabungkan pendekatan ini dengan gaya arsitektur lainnya untuk membuat arsitektur hibrid. Kombinasi umum termasuk layanan mikro dan pipa dan filter. Integrasikan arsitektur berbasis peristiwa untuk meningkatkan performa sistem dengan menghilangkan hambatan dan memberikan tekanan balik selama volume permintaan tinggi.

• Domain tertentu sering menjangkau beberapa produsen peristiwa, konsumen, atau saluran peristiwa. Perubahan pada domain tertentu mungkin memengaruhi banyak komponen.

Sumber daya terkait

• Video diskusi komunitas tentang pertimbangan memilih antara koreografi dan orkestrasi.

Arsitektur berbasis peristiwa terdiri dari produsen peristiwa yang menghasilkan aliran peristiwa, konsumen peristiwa yang mendengarkan peristiwa ini, dan saluran peristiwa yang mentransfer peristiwa dari produsen ke konsumen.

Peristiwa disampaikan hampir secara real time, sehingga konsumen dapat segera merespons peristiwa yang terjadi. Produsen dipisahkan dari konsumen: Produsen tidak tahu konsumen mana yang mendengarkan. Konsumen juga dipisahkan satu sama lain, dan setiap konsumen melihat semua peristiwa. Proses ini berbeda dari pola Konsumen yang Bersaing di mana konsumen menarik pesan dari antrean dan pesan hanya diproses satu kali, dengan asumsi bahwa tidak ada kesalahan. Dalam beberapa sistem, seperti Azure Internet of Things (IoT), peristiwa harus diserap pada volume tinggi.

Arsitektur berbasis peristiwa dapat menggunakan model terbitkan-berlangganan atau model aliran peristiwa.

• Pub/sub: Infrastruktur olahpesan terbitkan-berlangganan melacak langganan. Saat peristiwa diterbitkan, peristiwa tersebut akan dikirim ke setiap pelanggan. Peristiwa tidak dapat diputar ulang setelah diterima, dan pelanggan baru tidak melihat peristiwa tersebut.

• Streaming acara: Peristiwa ditulis ke log. Peristiwa diurutkan secara ketat dalam partisi dan tahan lama. Klien tidak berlangganan aliran. Sebagai gantinya, klien dapat membaca dari bagian mana pun dari aliran. Klien bertanggung jawab untuk memajukan posisi mereka di aliran. Itu berarti klien dapat bergabung kapan saja dan dapat memutar ulang peristiwa.

Di sisi konsumen, ada beberapa variasi umum:

• Pemrosesan peristiwa sederhana: Peristiwa segera memicu tindakan di konsumen. Misalnya, Anda dapat menggunakan Azure Functions dengan pemicu Azure Service Bus sehingga fungsi berjalan setiap kali pesan diterbitkan ke topik Bus Layanan.

• Korelasi peristiwa dasar: Konsumen memproses beberapa peristiwa bisnis diskrit, menghubungkannya dengan beberapa pengidentifikasi, dan mempertahankan informasi dari peristiwa sebelumnya untuk digunakan saat memproses peristiwa selanjutnya. Pustaka seperti NServiceBus dan MassTransit mendukung pola ini.

• Pemrosesan peristiwa yang kompleks: Konsumen menggunakan teknologi seperti Azure Stream Analytics untuk menganalisis serangkaian peristiwa dan mengidentifikasi pola dalam data peristiwa. Misalnya, Anda dapat mengagregasi pembacaan dari perangkat yang disematkan selama jendela waktu, dan menghasilkan pemberitahuan jika rata-rata pemindahan melewati ambang batas tertentu.

• Pemrosesan aliran peristiwa: Gunakan platform streaming data, seperti Azure IoT Hub atau Apache Kafka, sebagai alur untuk menyerap peristiwa dan mengumpankannya ke prosesor streaming. Prosesor aliran berfungsi untuk memproses atau mengubah aliran. Mungkin ada beberapa prosesor aliran untuk subsistem aplikasi yang berbeda. Pendekatan ini sangat cocok untuk beban kerja IoT.

Sumber peristiwa mungkin berada di luar sistem, seperti perangkat fisik dalam solusi IoT. Dalam hal ini, sistem harus dapat menyerap data pada volume dan throughput yang diperlukan sumber data.

Ada dua pendekatan utama untuk menyusun payload peristiwa. Ketika Anda memiliki kontrol atas konsumen peristiwa Anda, Anda dapat memutuskan struktur payload untuk setiap konsumen. Strategi ini memungkinkan Anda untuk mencampur pendekatan sesuai kebutuhan dalam satu beban kerja.

• Sertakan semua atribut yang diperlukan dalam payload: Gunakan pendekatan ini saat Anda ingin konsumen memiliki semua informasi yang tersedia tanpa perlu mengkueri sumber data eksternal. Namun, ini dapat menyebabkan masalah konsistensi data karena beberapa sistem rekaman, terutama setelah pembaruan. Manajemen kontrak dan penerapan versi juga dapat menjadi kompleks.

• Sertakan hanya kunci dalam payload: Dalam pendekatan ini, konsumen mengambil atribut yang diperlukan, seperti kunci primer, untuk mengambil data yang tersisa dari sumber data secara independen. Metode ini memberikan konsistensi data yang lebih baik karena memiliki satu sistem rekaman. Namun, ini dapat berkinerja lebih buruk daripada pendekatan pertama karena konsumen harus sering mengkueri sumber data. Anda memiliki lebih sedikit kekhawatiran mengenai kopling, bandwidth, manajemen kontrak, atau penerapan versi karena peristiwa yang lebih kecil dan kontrak yang lebih sederhana mengurangi kompleksitas.

Dalam diagram sebelumnya, setiap jenis konsumen ditampilkan sebagai satu kotak. Untuk menghindari konsumen menjadi satu titik kegagalan dalam sistem, biasanya memiliki beberapa instans konsumen. Beberapa instans mungkin juga diperlukan untuk menangani volume dan frekuensi peristiwa. Satu konsumen dapat memproses peristiwa pada beberapa utas. Penyiapan ini dapat menciptakan tantangan jika peristiwa harus diproses secara berurutan atau memerlukan semantik sekali persis. Untuk informasi selengkapnya, lihat Meminimalkan koordinasi.

Ada dua topologi utama dalam banyak arsitektur berbasis peristiwa:

• Topologi broker: Komponen menyiarkan kejadian sebagai peristiwa ke seluruh sistem. Komponen lain bertindak pada peristiwa atau mengabaikan peristiwa. Topologi ini berguna ketika alur pemrosesan peristiwa relatif sederhana. Tidak ada koordinasi atau orkestrasi pusat, sehingga topologi ini bisa dinamis. Topologi ini sangat dipisahkan, yang membantu memberikan skalabilitas, responsivitas, dan toleransi kesalahan komponen. Tidak ada komponen yang memiliki atau mengetahui status transaksi bisnis multistep apa pun, dan tindakan diambil secara asinkron. Selanjutnya, transaksi terdistribusi berisiko karena tidak ada cara asli untuk dimulai ulang atau diputar ulang. Anda perlu mempertimbangkan penanganan kesalahan dan strategi intervensi manual dengan cermat karena topologi ini dapat menjadi sumber inkonsistensi data.

• Topologi mediator: Topologi ini membahas beberapa kekurangan topologi broker. Ada mediator peristiwa yang mengelola dan mengontrol alur peristiwa. Mediator peristiwa mempertahankan status dan mengelola penanganan kesalahan dan memulai ulang kemampuan. Berbeda dengan topologi broker, dalam topologi ini, komponen menyiarkan kemunculan sebagai perintah dan hanya untuk saluran yang ditunjuk. Saluran ini biasanya merupakan antrean pesan. Konsumen diharapkan untuk memproses perintah ini. Topologi ini memberikan lebih banyak kontrol, penanganan kesalahan terdistribusi yang lebih baik, dan konsistensi data yang berpotensi lebih baik. Topologi ini memang memperkenalkan peningkatan kopling antar komponen, dan mediator peristiwa dapat menjadi hambatan atau kekhawatiran keandalan.

Kapan harus menggunakan arsitektur ini

Anda harus menggunakan arsitektur ini saat:

• Beberapa subsistem harus memproses peristiwa yang sama.
• Pemrosesan real time dengan jeda waktu minimum diperlukan.
• Pemrosesan peristiwa yang kompleks, seperti pencocokan pola atau agregasi dari jendela waktu ke waktu, diperlukan.
• Diperlukan volume tinggi dan kecepatan data yang tinggi, seperti, misalnya, IoT.

Keuntungan

Manfaat arsitektur ini adalah:

• Produsen dan konsumen dipisahkan.
• Tidak ada integrasi titik-ke-titik. Sangat mudah menambahkan konsumen baru ke sistem.
• Konsumen dapat segera menanggapi peristiwa saat terjadi.
• Sangat dapat diskalakan, elastis, dan terdistribusi.
• Subsistem memiliki tampilan independen aliran peristiwa.

Tantangan

• Pengiriman terjamin.

  Dalam beberapa sistem, terutama dalam skenario IoT, sangat penting untuk menjamin bahwa peristiwa disampaikan.

• Memproses peristiwa secara berurutan atau tepat sekali.

  Untuk ketahanan dan skalabilitas, setiap jenis konsumen biasanya berjalan dalam beberapa instans. Proses ini dapat menciptakan tantangan jika peristiwa harus diproses secara berurutan dalam jenis konsumen, atau jika logika pemrosesan pesan idempogen tidak diimplementasikan.

• Koordinasi pesan di seluruh layanan.

  Proses bisnis sering memiliki beberapa layanan yang menerbitkan dan berlangganan pesan untuk mencapai hasil yang konsisten di seluruh beban kerja. Anda dapat menggunakan pola alur kerja seperti pola Koreografi dan Orkestrasi Saga untuk mengelola alur pesan dengan andal di berbagai layanan.

• Penanganan kesalahan.

  Arsitektur berbasis peristiwa terutama menggunakan komunikasi asinkron. Tantangan dengan komunikasi asinkron adalah penanganan kesalahan. Salah satu cara untuk mengatasi masalah ini adalah dengan menggunakan prosesor penanganan kesalahan terpisah. Ketika konsumen peristiwa mengalami kesalahan, itu segera dan secara asinkron mengirim peristiwa yang salah ke prosesor penanganan kesalahan dan melanjutkan. Prosesor penanganan kesalahan mencoba memperbaiki kesalahan dan mengirim peristiwa kembali ke saluran penyerapan asli. Tetapi jika prosesor penanganan kesalahan gagal, prosesor dapat mengirim peristiwa yang salah ke administrator untuk pemeriksaan lebih lanjut. Jika Anda menggunakan prosesor penanganan kesalahan, peristiwa yang salah diproses dari urutan saat dikirim ulang.

• Kehilangan data.

  Tantangan lain dengan komunikasi asinkron adalah kehilangan data. Jika salah satu komponen mengalami crash sebelum berhasil memproses dan menyerahkan peristiwa ke komponen berikutnya, maka peristiwa dihilangkan dan tidak pernah masuk ke tujuan akhir. Untuk meminimalkan kemungkinan kehilangan data, pertahankan peristiwa dalam transit dan hapus atau hapus antrean peristiwa hanya ketika komponen berikutnya mengakui tanda terima peristiwa. Fitur-fitur ini dikenal sebagai mode pengakuan klien dan dukungan peserta terakhir.

• Implementasi pola respons permintaan tradisional.

  Terkadang produsen peristiwa memerlukan respons segera dari konsumen peristiwa, seperti mendapatkan kelayakan pelanggan sebelum melanjutkan pesanan. Dalam arsitektur berbasis peristiwa, komunikasi sinkron dapat dicapai dengan menggunakan pesan respons permintaan.

  Pola ini biasanya diimplementasikan dengan dua antrean: Antrean permintaan dan antrean respons. Produsen peristiwa mengirimkan permintaan asinkron ke antrean permintaan, menjeda operasi lain pada tugas tersebut, dan menunggu respons dalam antrean balasan. Pendekatan ini secara efektif mengubah pola ini menjadi proses yang sinkron. Konsumen peristiwa kemudian memproses permintaan dan mengirim balasan kembali melalui antrean respons. Pendekatan ini biasanya menggunakan ID sesi untuk pelacakan, sehingga produsen peristiwa mengetahui pesan mana dalam antrean respons yang terkait dengan permintaan tertentu. Permintaan asli juga dapat menentukan nama antrean respons, yang berpotensi sementara, dalam header balasan atau atribut kustom lain yang disepakati bersama.

• Pemeliharaan jumlah peristiwa yang sesuai.

  Menghasilkan sejumlah besar peristiwa halus dapat menjenuhkan dan membanjiri sistem, sehingga sulit untuk menganalisis alur keseluruhan peristiwa secara efektif. Masalah ini diperburuk ketika perubahan perlu digulung balik. Sebaliknya, peristiwa yang terlalu mengonsolidasikan juga dapat menciptakan masalah, yang mengakibatkan pemrosesan dan respons yang tidak perlu dari konsumen peristiwa.

  Untuk mencapai keseimbangan yang tepat, pertimbangkan konsekuensi peristiwa dan apakah konsumen perlu memeriksa payload peristiwa untuk menentukan respons mereka. Misalnya, jika Anda memiliki komponen pemeriksaan kepatuhan, mungkin cukup untuk menerbitkan hanya dua jenis peristiwa: sesuai dan tidak patuh. Pendekatan ini membantu memastikan bahwa hanya konsumen yang relevan yang memproses setiap peristiwa, yang mencegah pemrosesan yang tidak perlu.

Pertimbangan lain

• Jumlah data yang disertakan dalam suatu peristiwa dapat menjadi pertimbangan signifikan yang memengaruhi performa dan biaya. Anda dapat menyederhanakan kode pemrosesan dan menghilangkan pencarian tambahan dengan menempatkan semua informasi relevan yang diperlukan untuk diproses secara langsung dalam peristiwa tersebut. Saat Anda hanya menambahkan jumlah informasi minimal ke suatu peristiwa, seperti beberapa pengidentifikasi, Anda mengurangi waktu dan biaya transportasi. Namun, pendekatan ini memerlukan kode pemrosesan untuk mengambil informasi tambahan yang dibutuhkannya. Untuk informasi selengkapnya, lihat Menempatkan peristiwa Anda pada diet.

• Permintaan hanya terlihat oleh komponen penanganan permintaan. Tetapi peristiwa sering terlihat oleh beberapa komponen dalam beban kerja, bahkan jika komponen tersebut tidak atau tidak dimaksudkan untuk mengonsumsinya. Untuk beroperasi dengan pola pikir "asumsikan pelanggaran", perhatikan informasi apa yang Anda sertakan dalam peristiwa untuk mencegah paparan informasi yang tidak diinginkan.

• Banyak aplikasi menggunakan arsitektur berbasis peristiwa sebagai arsitektur utamanya. Anda dapat menggabungkan pendekatan ini dengan gaya arsitektur lainnya untuk membuat arsitektur hibrid. Kombinasi umum termasuk layanan mikro dan pipa dan filter. Integrasikan arsitektur berbasis peristiwa untuk meningkatkan performa sistem dengan menghilangkan hambatan dan memberikan tekanan balik selama volume permintaan tinggi.

• Domain tertentu sering menjangkau beberapa produsen peristiwa, konsumen, atau saluran peristiwa. Perubahan pada domain tertentu mungkin memengaruhi banyak komponen.

Sumber daya terkait

• Video diskusi komunitas tentang pertimbangan memilih antara koreografi dan orkestrasi.