Arsitektur berbasis peristiwa adalah pola desain software yang memungkinkan mikroservice bereaksi terhadap perubahan status, yang disebut peristiwa. Peristiwa dapat membawa status (seperti harga item atau alamat pengiriman) atau peristiwa dapat berupa ID (misalnya, notifikasi bahwa pesanan diterima atau dikirim). Peristiwa memicu microservice yang bekerja sama untuk mencapai tujuan bersama, tetapi tidak perlu mengetahui apa pun tentang satu sama lain kecuali format peristiwa. Meskipun beroperasi bersama, setiap microservice dapat menerapkan logika bisnis yang berbeda, dan memancarkan peristiwa outputnya sendiri.
Peristiwa memiliki karakteristik berikut:
- Ini adalah catatan tentang sesuatu yang telah terjadi.
- ID ini mencatat fakta tetap yang tidak dapat diubah atau dihapus.
- Hal ini terjadi terlepas dari apakah layanan menerapkan logika apa pun saat menggunakannya atau tidak.
- Data dapat dipertahankan tanpa batas waktu, dalam skala besar, dan digunakan berkali-kali sesuai kebutuhan.
Dalam sistem berbasis peristiwa, peristiwa dihasilkan oleh produsen peristiwa, diserap dan difilter oleh router peristiwa (atau broker), lalu didistribusikan ke konsumen peristiwa (atau sink) yang sesuai. Peristiwa diteruskan ke konsumen berdasarkan langganan yang ditentukan oleh satu atau beberapa pendaftaran yang cocok (saat menggunakan Eventarc Advanced) atau satu atau beberapa pemicu yang cocok (saat menggunakan Eventarc Standard). Ketiga komponen ini—produsen peristiwa, router peristiwa, konsumen peristiwa—tidak terikat dan dapat di-deploy, diperbarui, dan diskalakan secara independen:
Router peristiwa menghubungkan berbagai layanan dan merupakan media yang digunakan untuk mengirim dan menerima pesan. Proses ini menjalankan respons terhadap peristiwa asli yang dihasilkan oleh produsen peristiwa dan mengirimkan respons ini ke hilir ke konsumen yang sesuai. Peristiwa ditangani secara asinkron dan hasilnya ditentukan saat layanan bereaksi terhadap peristiwa atau terpengaruh olehnya, seperti dalam diagram alur peristiwa yang sangat disederhanakan berikut:
Kapan harus menggunakan arsitektur berbasis peristiwa
Pertimbangkan penggunaan berikut saat mendesain sistem Anda.
- Untuk memantau dan menerima pemberitahuan jika ada anomali atau perubahan pada bucket penyimpanan, tabel database, mesin virtual, atau resource lainnya.
- Untuk menyebarkan satu peristiwa ke beberapa konsumen. Router peristiwa akan mendorong peristiwa ke semua konsumen yang sesuai, tanpa Anda harus menulis kode yang disesuaikan. Setiap layanan kemudian dapat memproses peristiwa secara paralel, tetapi berbeda.
- Untuk menyediakan interoperabilitas antara berbagai technology stack sekaligus mempertahankan independensi setiap stack.
- Untuk mengoordinasikan sistem dan tim yang beroperasi dan di-deploy di berbagai region dan akun. Anda dapat mengatur ulang kepemilikan microservice. Ada lebih sedikit dependensi lintas tim dan Anda dapat bereaksi lebih cepat terhadap perubahan yang seharusnya terhambat oleh penghalang akses data.
Manfaat arsitektur berbasis peristiwa
Berikut beberapa keuntungan saat membangun arsitektur berbasis peristiwa.
Pengaitan longgar dan peningkatan fleksibilitas developer
Produsen acara dipisahkan secara logis dari konsumen acara. Pemisahan antara produksi dan penggunaan peristiwa ini berarti bahwa layanan dapat beroperasi, tetapi dapat diskalakan, diupdate, dan di-deploy secara terpisah satu sama lain.
Loose coupling mengurangi dependensi dan memungkinkan Anda menerapkan layanan dalam bahasa dan framework yang berbeda. Anda dapat menambahkan atau menghapus produsen dan penerima peristiwa tanpa harus mengubah logika di salah satu layanan. Anda tidak perlu menulis kode kustom untuk melakukan polling, memfilter, dan merutekan peristiwa.
Peristiwa asinkron dan ketahanan
Dalam sistem berbasis peristiwa, peristiwa dibuat secara asinkron, dan dapat dikeluarkan saat terjadi tanpa menunggu respons. Komponen yang digabungkan secara longgar berarti jika satu layanan gagal, layanan lainnya tidak terpengaruh. Jika perlu, Anda dapat mencatat peristiwa sehingga layanan penerima dapat melanjutkan dari titik kegagalan, atau memutar ulang peristiwa sebelumnya.
Pesan berbasis push, streaming peristiwa real-time, dan biaya yang lebih rendah
Sistem berbasis peristiwa memungkinkan pengiriman pesan berbasis push dan klien dapat menerima update tanpa perlu terus-menerus melakukan polling pada layanan jarak jauh untuk perubahan status. Pesan yang dikirim ini dapat digunakan untuk pemrosesan dan transformasi data secara langsung, serta analisis real-time. Selain itu, dengan polling yang lebih sedikit, I/O jaringan akan berkurang dan biaya akan menurun.
Pengauditan dan sumber peristiwa yang disederhanakan
Lokasi terpusat perute peristiwa menyederhanakan audit, dan memungkinkan Anda mengontrol siapa yang dapat berinteraksi dengan perute, serta pengguna dan resource mana yang memiliki akses ke data Anda. Anda juga dapat mengenkripsi data Anda baik saat transit maupun saat nonaktif.
Selain itu, Anda dapat memanfaatkan sumber peristiwa, pola arsitektur yang mencatat semua perubahan yang dilakukan pada status aplikasi, dalam urutan yang sama seperti yang diterapkan semula. Sumber peristiwa menyediakan log peristiwa yang tidak dapat diubah yang dapat disimpan untuk tujuan audit, untuk membuat ulang status historis, atau sebagai narasi kanonis untuk menjelaskan keputusan yang didorong oleh bisnis.
Pertimbangan arsitektur
Arsitektur berbasis peristiwa mungkin mengharuskan Anda mendekati desain aplikasi dengan cara baru. Meskipun cocok untuk aplikasi yang menggunakan microservice atau komponen yang tidak terikat, Anda juga harus mempertimbangkan hal berikut:
Dapatkah sumber peristiwa Anda menjamin pengiriman jika Anda perlu memproses setiap peristiwa?
Sumber peristiwa ini harus tahan lama dan andal.
Dapatkah aplikasi Anda menangani beberapa permintaan asinkron?
Performa sistem Anda tidak boleh bergantung pada cakupan global atau database yang tidak elastis.
Bagaimana cara Anda ingin melacak alur peristiwa?
Arsitektur berbasis peristiwa mendukung pelacakan dinamis menggunakan layanan pemantauan, tetapi tidak mendukung pelacakan statis menggunakan analisis kode.
Apakah Anda ingin menggunakan data di sumber peristiwa untuk membangun ulang status?
Anda harus mempertimbangkan cara memastikan data Anda telah di-duplikat dan diurutkan.
Langkah berikutnya
- Untuk memahami cara Eventarc Advanced menangani peristiwa, lihat Ringkasan Eventarc Advanced.
- Untuk memahami cara Eventarc Standard menangani peristiwa, lihat Ringkasan Eventarc Standard.