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. 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.
Ada dua topologi utama dalam banyak arsitektur berbasis peristiwa:
Topologi broker. Komponen menyiarkan kejadian sebagai peristiwa ke seluruh sistem, dan komponen lain bertindak berdasarkan peristiwa atau hanya mengabaikan peristiwa. Topologi ini berguna ketika alur pemrosesan peristiwa relatif sederhana. Tidak ada koordinasi atau orkestrasi pusat, sehingga topologi ini bisa sangat 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. Penanganan kesalahan dan strategi intervensi manual perlu dipertimbangkan 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. Tidak seperti topologi broker, komponen menyiarkan kemunculan sebagai perintah dan hanya untuk saluran yang ditunjuk, biasanya antrean pesan. Perintah ini tidak diharapkan diabaikan oleh konsumen mereka. Topologi ini menawarkan 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
- 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, 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.
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.
Penanganan kesalahan.
Arsitektur berbasis peristiwa menggunakan terutama komunikasi asinkron. Tantangan dengan komunikasi asinkron adalah penanganan kesalahan. Salah satu cara untuk mengatasi masalah ini adalah dengan menggunakan prosesor penanganan kesalahan terpisah. Jadi, 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, maka prosesor dapat mengirim peristiwa yang salah ke administrator untuk pemeriksaan lebih lanjut. Jika Anda menggunakan prosesor penanganan kesalahan, peristiwa yang salah akan diproses secara tidak berurutan 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 telah mengakui penerimaan peristiwa. Fitur-fitur ini biasanya dikenal sebagai mode pengakuan klien dan dukungan peserta terakhir.
Menerapkan 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 melalui pesan respons permintaan.
Pola ini biasanya diterapkan dengan menggunakan beberapa 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; mengubah ini secara efektif menjadi proses 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.
Mempertahankan 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 memungkinkan setiap peristiwa diproses hanya oleh konsumen yang relevan, mencegah pemrosesan yang tidak perlu.
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.
- Banyak aplikasi menggunakan arsitektur berbasis peristiwa sebagai arsitektur utamanya; namun, pendekatan ini dapat dikombinasikan dengan gaya arsitektur lainnya, menghasilkan arsitektur hibrid. Kombinasi umum termasuk layanan mikro dan pipa dan filter. Mengintegrasikan arsitektur berbasis peristiwa 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 berdampak pada banyak komponen.
Sumber daya terkait
- Video diskusi komunitas tentang pertimbangan memilih antara koreografi dan orkestrasi.