Apa itu Arsitektur yang Didorong Peristiwa?
Arsitektur yang didorong peristiwa menggunakan peristiwa untuk memicu dan berkomunikasi antara layanan yang dipisahkan dan umum dalam aplikasi modern yang dibangun dengan layanan mikro. Peristiwa adalah perubahan keadaan, atau pembaruan, seperti item yang ditempatkan di keranjang belanja di situs web perdagangan elektronik. Peristiwa dapat membawa keadaan (item yang dibeli, harganya, dan alamat pengantaran) atau peristiwa dapat berupa pengidentifikasi (pemberitahuan bahwa pesanan telah dikirim).
Arsitektur yang didorong peristiwa memiliki tiga komponen utama: prosedur peristiwa, perute peristiwa, dan konsumen peristiwa. Produsen memublikasikan peristiwa ke perute, yang memfilter dan mendorong peristiwa ke konsumen. Layanan produsen dan layanan konsumen dipisahkan, yang memungkinkan layanan untuk diskalakan, diperbarui, dan dilakukan deployment secara terpisah.
Untuk memahami lebih dalam, lihat seri Bincang Teknologi Online AWS tentang Cara Menggunakan Amazon EventBridge untuk Membangun Arsitektur Berbasis Peristiwa Terpisah. Pelajari dasar-dasar arsitektur berbasis peristiwa dan mulai Amazon EventBridge, termasuk membuat bus peristiwa, menyiapkan sumber peristiwa SaaS, dan banyak lagi.
Manfaat arsitektur berbasis peristiwa
Menskalakan dan gagal secara independen
Dengan memisahkan layanan Anda, layanan tersebut hanya mengetahui keberadaan perute peristiwa, bukan satu sama lain. Ini artinya layanan Anda dapat saling berinteraksi, tetapi jika salah satu layanan mengalami kegagalan, layanan lain akan tetap berjalan. Perute peristiwa bertindak sebagai penyangga elastis yang akan mengakomodasi lonjakan beban kerja.
Mengembangkan dengan agility (ketangkasan)
Anda tidak perlu lagi menulis kode kustom untuk memilih, memfilter, dan merutekan peristiwa; perute peristiwa akan otomatis memfilter dan mendorong peristiwa ke konsumen. Perute juga akan menghilangkan kebutuhan akan koordinasi intens antara layanan produsen dan konsumen, yang mempercepat proses pengembangan Anda.
Mengaudit dengan mudah
Perute peristiwa bertindak sebagai lokasi terpusat untuk mengaudit aplikasi Anda dan menentukan kebijakan. Kebijakan ini dapat membatasi siapa yang dapat memublikasikan dan berlangganan perute serta mengontrol pengguna dan sumber daya mana yang memiliki izin untuk mengakses data Anda. Anda juga dapat mengenkripsi peristiwa bergerak dan diam.
Memangkas biaya
Arsitektur yang didorong peristiwa didasarkan pada dorongan, jadi semua hal yang terjadi sesuai permintaan karena perute dapat melihat peristiwa. Dengan demikian, Anda tidak membayar polling kontinu untuk memeriksa peristiwa. Ini artinya lebih sedikit konsumsi bandwith jaringan, lebih sedikit pemanfaatan CPU, lebih sedikit kapasitas armada siaga, dan lebih sedikit persinggungan SSL/TLS.
Cara kerjanya: arsitektur contoh
Berikut contoh arsitektur yang didorong peristiwa untuk sebuah situs e-commerce. Dengan arsitektur ini, situs dapat bereaksi terhadap perubahan dari berbagai sumber selama periode puncak permintaan, tanpa mengganggu aplikasi atau menyediakan sumber daya terlalu banyak.
Kapan harus menggunakan arsitektur ini
Replikasi data lintas akun dan lintas-wilayah
Anda dapat menggunakan arsitektur yang didorong peristiwa untuk mengoordinasikan sistem di antara berbagai tim yang beroperasi dan melakukan deployment di berbagai wilayah dan akun berbeda. Dengan menggunakan perute peristiwa untuk mentransfer data di antara sistem, Anda dapat mengembangkan, menskalakan, dan melakukan deployment layanan secara independen dari tim lainnya.
Pemantauan dan pengiriman peringatan status sumber daya
Agar tidak perlu terus-menerus memeriksa sumber daya, Anda dapat menggunakan arsitektur yang didorong peristiwa untuk memantau dan menerima peringatan mengenai anomali, perubahan, atau pembaruan. Sumber daya ini dapat meliputi bucket penyimpanan, tabel basis data, fungsi nirserver, simpul komputasi, dan banyak lagi.
Penyebarluasan dan pemrosesan paralel
Jika Anda memiliki banyak sistem yang perlu beroperasi untuk merespons peristiwa, Anda dapat menggunakan arsitektur yang didorong peristiwa untuk menyebarluaskan peristiwa tanpa perlu menulis kode kustom untuk mendorong ke setiap konsumen. Perute ini akan mendorong peristiwa ke sistem, yang masing-masing dapat memproses peristiwa secara paralel dengan tujuan berbeda.
Integrasi sistem heterogen
Jika Anda memiliki sistem yang berjalan di tumpukan berbeda, Anda dapat menggunakan arsitektur yang didorong peristiwa untuk berbagi informasi antartumpukan tanpa pemisahan. Perute peristiwa menetapkan prosedur tidak langsung dan interoperabilitas di antara sistem, sehingga dapat bertukar pesan dan data sambil tetap agnostik.
Apakah sebaiknya Anda menggunakan arsitektur yang didorong peristiwa?
Arsitektur yang didorong peristiwa ideal untuk meningkatkan ketangkasan dan bergerak cepat. Arsitektur ini lazim ditemukan di aplikasi modern yang menggunakan layanan mikro, atau aplikasi yang memiliki komponen terpisah. Saat mengadopsi arsitektur yang didorong peristiwa, Anda mungkin perlu memikirkan kembali cara Anda melihat desain aplikasi. Untuk mempersiapkan kesuksesan, pertimbangkan hal-hal berikut:
• Daya tahan sumber peristiwa. Sumber peristiwa Anda seharusnya andal dan menjamin pengiriman jika Anda perlu memproses setiap peristiwa.
• Persyaratan kontrol performa Anda. Aplikasi Anda seharusnya mampu menangani sifat perute peristiwa yang asinkron.
• Pelacakan alur peristiwa Anda. Prosedur tidak langsung yang diperkenalkan oleh arsitektur yang didorong peristiwa memungkinkan pelacakan dinamis melalui layanan pemantauan, tetapi bukan pelacakan statis melalui analisis kode.
• Data di sumber peristiwa Anda. Jika Anda perlu membangun ulang status, sumber peristiwa sebaiknya dideduplikasi dan diurutkan.
Dari mana harus memulai
Terdapat dua tipe perute utama yang digunakan dalam arsitektur yang didorong peristiwa: bus peristiwa dan topik peristiwa. Di AWS, kami menawarkan Amazon EventBridge untuk membangun bus peristiwa dan Amazon Simple Notification Service (SNS) untuk membangun topik peristiwa.
Amazon EventBridge direkomendasikan saat Anda ingin membangun aplikasi yang bereaksi terhadap peristiwa dari aplikasi SaaS, layanan AWS, atau aplikasi kustom. EventBridge menggunakan skema yang ditentukan sebelumnya untuk peristiwa dan memungkinkan Anda membuat aturan yang diterapkan di seluruh bodi peristiwa untuk difilter sebelum didorong ke konsumen.
Amazon SNS direkomendasikan saat Anda ingin membangun aplikasi yang bereaksi terhadap peristiwa throughput tinggi dan latensi rendah yang dipublikasikan oleh aplikasi, layanan mikro, atau layanan AWS lain, atau untuk aplikasi yang memerlukan penyebarluasan yang sangat tinggi (ribuan atau jutaan titik akhir). Topik SNS agnostik terhadap skema peristiwa yang masuk.
