Arsitektur berbasis peristiwa adalah pola desain software tempat microservice 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 satu sama lain kecuali format peristiwa. Meskipun beroperasi bersama, setiap microservice dapat menerapkan logika bisnis yang berbeda, dan memunculkan peristiwa output-nya sendiri.
Peristiwa memiliki karakteristik berikut:
- Ini adalah catatan tentang sesuatu yang telah terjadi.
- Ini menangkap fakta yang tidak dapat diubah yang tidak dapat diubah atau dihapus.
- Hal ini terjadi terlepas dari apakah layanan menerapkan logika apa pun setelah menggunakannya.
- Data dapat dipertahankan tanpa batas, dalam skala besar, dan digunakan sebanyak yang diperlukan.
Dalam sistem berbasis peristiwa, peristiwa dihasilkan oleh produser 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—produser peristiwa, router peristiwa, konsumen peristiwa—dipisah dan dapat di-deploy, diupdate, dan diskalakan secara independen:
Router peristiwa menautkan berbagai layanan dan merupakan media tempat pesan dikirim dan diterima. Fungsi ini mengeksekusi respons terhadap peristiwa asli yang dihasilkan oleh produsen peristiwa dan mengirim respons ini ke downstream ke konsumen yang sesuai. Peristiwa ditangani secara asinkron dan hasilnya ditentukan saat layanan bereaksi terhadap peristiwa atau terpengaruh olehnya, seperti dalam diagram berikut tentang alur peristiwa yang sangat disederhanakan:
Kapan harus menggunakan arsitektur berbasis peristiwa
Pertimbangkan penggunaan berikut saat mendesain sistem Anda.
- Untuk memantau dan menerima pemberitahuan tentang anomali atau perubahan pada bucket penyimpanan, tabel database, virtual machine, 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 antar-technology stack yang berbeda sekaligus mempertahankan independensi setiap stack.
- Untuk mengoordinasikan sistem dan tim yang beroperasi di dan men-deploy di berbagai region dan akun. Anda dapat mengatur ulang kepemilikan microservice. Ada dependensi lintas tim yang lebih sedikit dan Anda dapat bereaksi lebih cepat terhadap perubahan yang akan terhambat oleh hambatan akses data.
Manfaat arsitektur berbasis peristiwa
Berikut adalah beberapa keuntungan saat membuat arsitektur berbasis peristiwa.
Pengaitan longgar dan peningkatan fleksibilitas developer
Produsen peristiwa secara logis dipisahkan dari konsumen peristiwa. Pemisahan antara produksi dan penggunaan peristiwa ini berarti bahwa layanan dapat dioperasikan secara bersama-sama, tetapi dapat diskalakan, diupdate, dan di-deploy secara independen.
Penggabungan longgar 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 satu layanan. Anda tidak perlu menulis kode kustom untuk melakukan polling, memfilter, dan merutekan peristiwa.
Ketahanan dan peristiwa asinkron
Dalam sistem berbasis peristiwa, peristiwa dibuat secara asinkron, dan dapat diterbitkan saat terjadi tanpa menunggu respons. Komponen yang terikat secara longgar berarti jika satu layanan gagal, layanan lainnya tidak akan terpengaruh. Jika perlu, Anda dapat mencatat peristiwa ke dalam log sehingga layanan penerima dapat dilanjutkan dari titik kegagalan, atau memutar ulang peristiwa sebelumnya.
Pesan berbasis push, streaming peristiwa real-time, dan biaya yang lebih rendah
Sistem berbasis peristiwa memungkinkan pesan berbasis push dan klien dapat menerima update tanpa perlu terus melakukan polling 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, terjadi pengurangan I/O jaringan, dan penurunan biaya.
Audit dan sumber peristiwa yang disederhanakan
Lokasi terpusat router peristiwa menyederhanakan audit, dan memungkinkan Anda mengontrol siapa yang dapat berinteraksi dengan router, 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 menggunakan sumber peristiwa, pola arsitektur yang mencatat semua perubahan yang dilakukan pada status aplikasi, dalam urutan yang sama seperti yang diterapkan pada awalnya. Sumber peristiwa menyediakan log peristiwa yang tidak dapat diubah yang dapat disimpan untuk tujuan audit, untuk membuat ulang status historis, atau sebagai narasi kanonik untuk menjelaskan keputusan berbasis bisnis.
Pertimbangan arsitektur
Arsitektur berbasis peristiwa mungkin mengharuskan Anda mendekati desain aplikasi dengan cara baru. Meskipun sangat cocok untuk aplikasi yang menggunakan microservice atau komponen yang dipisahkan, Anda juga harus mempertimbangkan hal berikut:
Dapatkah sumber peristiwa Anda menjamin pengiriman jika Anda perlu memproses setiap peristiwa?
Sumber peristiwa 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 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 membuat ulang status?
Anda harus mempertimbangkan cara memastikan data Anda dihapus duplikatnya 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.