Arsitektur berbasis peristiwa terdiri dari produsen peristiwa yang menghasilkan aliran peristiwa, dan konsumen peristiwa yang mendengarkan peristiwa.
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. Ini berbeda dengan pola Konsumen yang Bersaing, di mana konsumen menarik pesan dari antrean dan pesan diproses hanya sekali (dengan asumsi tidak ada kesalahan). Dalam beberapa sistem, seperti IoT, peristiwa harus diserap pada volume yang sangat tinggi.
Arsitektur berbasis peristiwa dapat menggunakan model publikasi/berlangganan (juga disebut pub/sub) atau model aliran peristiwa.
Pub/sub: Infrastruktur olahpesan melacak langganan. Saat peristiwa diterbitkan, peristiwa tersebut akan dikirim ke setiap pelanggan. Setelah acara diterima, peristiwa tidak dapat diputar ulang, dan pelanggan baru tidak melihat peristiwa tersebut.
Streaming peristiwa: Peristiwa ditulis ke log. Peristiwa diatur secara ketat (dalam partisi) dan tahan lama. Klien tidak berlangganan aliran, sebaliknya klien dapat membaca dari bagian mana pun dari aliran. Klien bertanggung jawab untuk memajukan posisinya di aliran. Itu artinya klien dapat bergabung kapan saja, dan dapat memutar ulang peristiwa.
Di sisi konsumen, ada beberapa variasi umum:
Pemrosesan acara sederhana. Suatu peristiwa segera memicu tindakan pada konsumen. Misalnya, Anda bisa menggunakan Azure Functions dengan pemicu Bus Layanan, sehingga fungsi dijalankan setiap kali pesan diterbitkan ke topik Bus Layanan.
Korelasi peristiwa dasar. Konsumen perlu memproses sejumlah kecil peristiwa bisnis diskrit, biasanya berkorelasi dengan beberapa pengidentifikasi, mempertahankan beberapa informasi dari peristiwa sebelumnya untuk digunakan saat memproses peristiwa selanjutnya. Pola ini didukung oleh pustaka seperti NServiceBus dan MassTransit.
Pemrosesan kejadian kompleks. Konsumen memproses serangkaian peristiwa, mencari pola dalam data peristiwa, menggunakan teknologi seperti Azure Stream Analytics. Misalnya, Anda dapat mengumpulkan pembacaan dari perangkat yang disematkan selama jangka waktu tertentu, dan membuat notifikasi jika rata-rata bergerak melewati ambang batas tertentu.
Pemrosesan aliran acara. Gunakan platform aliran data, seperti Azure IoT Hub atau Apache Kafka, sebagai alur untuk menyerap peristiwa dan memasukkannya ke prosesor aliran. 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 oleh sumber data.
Dalam diagram logika di atas, setiap jenis konsumen ditampilkan sebagai satu kotak. Dalam praktiknya, umumnya ini memiliki banyak instans konsumen, agar konsumen tidak menjadi satu titik kegagalan dalam sistem. Beberapa instans mungkin juga diperlukan untuk menangani volume dan frekuensi peristiwa. Selain itu, satu konsumen dapat memproses peristiwa di beberapa utas. Ini dapat menciptakan tantangan jika peristiwa harus diproses secara berurutan atau memerlukan semantik yang tepat sekali. Lihat Meminimalkan Koordinasi.
Kapan harus menggunakan arsitektur ini
- Beberapa subsistem harus memproses peristiwa yang sama.
- Pemrosesan real time dengan jeda waktu minimum.
- Pemrosesan peristiwa yang kompleks, seperti pencocokan pola atau agregasi dari waktu ke waktu.
- Volume tinggi dan kecepatan data yang tinggi, seperti IoT.
Keuntungan
- Produsen dan konsumen dipisahkan.
- Tidak ada integrasi titik-ke-titik. Sangat mudah menambahkan konsumen baru ke sistem.
- Konsumen dapat merespons peristiwa segera setelah mereka tiba.
- Sangat dapat diskalakan 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. Setiap jenis konsumen biasanya berjalan dalam beberapa instans, untuk ketahanan dan skalabilitas. Ini dapat menciptakan tantangan jika peristiwa harus diproses secara berurutan (dalam jenis konsumen), atau logika pemrosesan pesan idempogen tidak diimplementasikan.
- Mengoordinasikan pesan di seluruh layanan. Proses bisnis sering melibatkan beberapa penerbitan layanan dan berlangganan pesan untuk mencapai hasil yang konsisten di seluruh beban kerja. Pola alur kerja seperti pola Koreografi dan Orkestrasi Saga dapat digunakan untuk mengelola alur pesan dengan andal di berbagai layanan.
Pertimbangan tambahan
- Jumlah data yang disertakan dalam suatu peristiwa dapat menjadi pertimbangan signifikan yang memengaruhi performa dan biaya. Memasukkan semua informasi relevan yang diperlukan untuk pemrosesan dalam peristiwa itu sendiri dapat menyederhanakan kode pemrosesan dan menyimpan pencarian tambahan. Memasukkan jumlah minimal informasi dalam suatu peristiwa, seperti hanya beberapa pengidentifikasi, akan mengurangi waktu dan biaya transportasi, tetapi memerlukan kode pemrosesan untuk mencari informasi tambahan yang dibutuhkan. Untuk informasi selengkapnya tentang ini, lihat postingan blog ini.
- Meskipun permintaan hanya terlihat oleh komponen penanganan permintaan, peristiwa sering terlihat oleh beberapa komponen dalam beban kerja, bahkan jika komponen tersebut tidak atau tidak dimaksudkan untuk mengonsumsinya. Beroperasi dengan pola pikir "asumsikan pelanggaran", perhatikan informasi apa yang Anda sertakan dalam peristiwa untuk mencegah paparan informasi yang tidak diinginkan.
Sumber daya terkait
- Video diskusi komunitas tentang pertimbangan memilih antara koreografi dan orkestrasi.