Memisahkan microservice melalui perutean peristiwa asinkron memungkinkan Anda membangun sistem terdistribusi yang bereaksi terhadap perubahan status secara independen. Alih-alih mengandalkan panggilan layanan ke layanan langsung, produsen peristiwa memublikasikan notifikasi yang tidak dapat diubah, sementara router peristiwa (atau broker) memfilter dan menyebarkan pesan ke konsumen peristiwa (atau sink) downstream. Pemisahan ini membantu Anda men-deploy, menskalakan, dan mengupdate komponen secara terpisah tanpa merusak layanan dependen.
Anda dapat mengelola pengiriman peristiwa dengan menentukan pendaftaran saat menggunakan Eventarc Advanced atau dengan menentukan pemicu saat menggunakan Eventarc Standard.
Ringkasan arsitektur
Arsitektur berbasis peristiwa adalah pola desain software yang memungkinkan 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 telah diterima atau dikirim). Peristiwa ini memicu microservice yang bekerja sama untuk mencapai tujuan bersama, tetapi tidak harus mengetahui apa pun tentang 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:
- Log adalah catatan tentang sesuatu yang telah terjadi.
- Log ini mencatat fakta yang tidak dapat diubah atau dihapus.
- Hal ini terjadi terlepas dari apakah layanan menerapkan logika apa pun saat menggunakannya atau tidak.
- Data ini dapat dipertahankan tanpa batas waktu, dalam skala besar, dan digunakan sebanyak yang diperlukan.
Komponen inti
Dalam sistem berbasis peristiwa, tiga komponen—produsen peristiwa, router peristiwa, konsumen peristiwa—dipisahkan dan dapat di-deploy, diupdate, dan diskalakan secara independen:
Router peristiwa menautkan berbagai layanan dan merupakan media yang digunakan untuk mengirim dan menerima pesan. Broker ini mengeksekusi respons terhadap peristiwa asli yang dihasilkan oleh produsen peristiwa dan mengirimkan respons ini 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 terkait 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 memberikan interoperabilitas antara berbagai stack teknologi sekaligus mempertahankan independensi setiap stack.
- Untuk mengoordinasikan sistem dan tim yang beroperasi dan melakukan deployment di berbagai region dan akun. Anda dapat mengatur ulang kepemilikan microservice. Dependensi lintas tim akan berkurang dan Anda dapat bereaksi lebih cepat terhadap perubahan yang mungkin terhambat oleh hambatan akses data.
Manfaat arsitektur berbasis peristiwa
Berikut adalah beberapa keuntungan saat membangun arsitektur berbasis peristiwa.
Pengaitan longgar dan peningkatan ketangkasan developer
Produsen peristiwa dipisahkan secara logis dari konsumen peristiwa. Pemisahan antara produksi dan konsumsi peristiwa ini berarti bahwa layanan dapat dioperasikan, tetapi dapat diskalakan, diupdate, dan di-deploy secara independen satu sama lain.
Penggabungan longgar mengurangi dependensi dan memungkinkan Anda menerapkan layanan dalam berbagai bahasa dan framework. Anda dapat menambahkan atau menghapus produsen dan penerima peristiwa tanpa harus mengubah logika di layanan mana pun. Anda tidak perlu menulis kode kustom untuk melakukan polling, memfilter, dan merutekan peristiwa.
Peristiwa asinkron dan ketahanan
Dalam sistem berbasis peristiwa, peristiwa dihasilkan secara asinkron, dan dapat dikeluarkan saat terjadi tanpa menunggu respons. Komponen yang digabungkan 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 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 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.
Penyederhanaan audit dan sumber peristiwa
Lokasi router peristiwa yang terpusat 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 dalam pengiriman maupun dalam penyimpanan.
Selain itu, Anda dapat menggunakan sumber peristiwa, pola arsitektur yang mencatat semua perubahan yang dilakukan pada status aplikasi, dalam urutan yang sama seperti yang awalnya diterapkan. 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 melakukan pendekatan 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 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 membangun ulang status?
Anda harus mempertimbangkan cara untuk memastikan data Anda telah diurutkan dan dideduplikasi.
Langkah berikutnya
- Untuk memahami cara Eventarc Advanced menangani peristiwa, lihat Ringkasan Eventarc Advanced.
- Untuk memahami cara Eventarc Standard menangani peristiwa, lihat Ringkasan Eventarc Standard.