Apa itu arsitektur yang didorong peristiwa (EDA)?
Arsitektur yang didorong peristiwa (EDA) adalah pola arsitektur modern yang dibangun dari layanan kecil terpisah yang menerbitkan, menggunakan, atau merutekan peristiwa.
Peristiwa mewakili perubahan keadaan, atau pembaruan. Misalnya: item yang ditempatkan di keranjang belanja, file yang diunggah ke sistem penyimpanan, atau pesanan yang siap dikirim. Peristiwa dapat membawa keadaan (seperti nama item, harga, atau kuantitas dalam pesanan) atau hanya berisi pengidentifikasi (misalnya, "pesanan #8942 telah dikirim") yang diperlukan untuk mencari informasi terkait.
Tidak seperti model yang didorong permintaan tradisional, EDA mempromosikan penggabungan longgar antara layanan produsen dan konsumen. Penggabungan longgar ini membuatnya lebih mudah untuk menskalakan, memperbarui, dan secara mandiri melakukan deployment komponen sistem yang terpisah.
Mengapa arsitektur terpisah itu penting?
Banyak organisasi menemukan bahwa aplikasi monolitik, basis data, dan teknologi berdampak negatif pada inovasi dan peningkatan pengalaman pengguna. Aplikasi dan basis data lama mengurangi opsi Anda untuk mengadopsi kerangka kerja teknologi modern serta membatasi daya saing dan inovasi Anda. Namun, saat Anda memodernisasi aplikasi dan penyimpanan datanya, keduanya menjadi lebih mudah diskalakan dan lebih cepat dikembangkan.
Strategi data terpisah meningkatkan toleransi kesalahan dan ketahanan, sehingga membantu mempercepat waktu untuk memasarkan (TTM) bagi fitur aplikasi baru Anda.
Untuk informasi selengkapnya mengenai keuntungan dari memodernisasi aplikasi monolitik, lihat Mengaktifkan persistensi data dalam layanan mikro di Panduan Perskriptif AWS.
Apa manfaat arsitektur yang didorong peristiwa (EDA)?
Arsitektur yang didorong peristiwa (EDA) mempromosikan penggabungan longgar antara komponen sistem, yang mengarah ke ketangkasan yang lebih besar. Layanan mikro dapat diskalakan secara independen, gagal tanpa memengaruhi layanan lain, dan mengurangi kerumitan alur kerja. Peristiwa dapat dirutekan, di-buffer, dan dicatat untuk tujuan audit. Alur peristiwa berbasis push dapat beroperasi secara waktu nyata, memotong biaya yang terkait dengan pembuatan dan pengoperasian kode yang terus-menerus melakukan polling sistem untuk perubahan.
Menskalakan dan gagal secara independen
Dengan memisahkan layanan, komponen dalam arsitektur yang didorong peristiwa dapat diskalakan dan gagal secara independen, meningkatkan ketahanan aplikasi. Hal ini menjadi semakin penting seiring dengan bertambahnya jumlah integrasi antar layanan. Jika satu layanan mengalami kegagalan, layanan lainnya dapat tetap berjalan.
Arsitektur yang didoring peristiwa juga dapat mempermudah desain yang mendekati sistem waktu nyata, membantu organisasi beralih dari pemrosesan berbasis batch. Peristiwa dihasilkan ketika status aplikasi berubah. Saat skala peristiwa naik, begitu juga lapisan yang memproses peristiwa.
Peristiwa biasanya dipublikasikan ke layanan perpesanan yang berperilaku seperti penyangga elastis antara layanan mikro dan membantu menangani penskalaan. Peristiwa mungkin juga dikirim ke layanan router yang dapat memfilter dan merutekan pesan berdasarkan konten peristiwa. Akibatnya, aplikasi yang didorong peristiwa dapat lebih terukur dan menawarkan redundansi yang lebih besar daripada aplikasi monolitik.
Mengembangkan dengan ketangkasan
Dengan arsitektur yang didorong peristiwa dan router peristiwa, developer tidak perlu lagi menulis kode khusus untuk melakukan polling, memfilter, dan merutekan peristiwa. Router peristiwa secara otomatis memfilter dan mengirimkan peristiwa ke konsumen. Router juga menghilangkan kebutuhan akan koordinasi berat antara produsen dan layanan konsumen, yang meningkatkan ketangkasan developer.
Arsitektur yang didorong peristiwa berbasis push, yang berarti bahwa segala sesuatu terjadi sesuai permintaan saat peristiwa dikirim ke router dan sistem hilir, tanpa perlu menginformasikan layanan yang bergantung. Karena itu, infrastruktur dan sumber daya dapat menaikkan dan menurunkan skala dengan volume peristiwa, yang mengurangi biaya untuk memproses beban kerja dan mengoperasikan aplikasi yang di-deploy.
Membangun sistem yang dapat diperluas
Arsitektur yang didorong peristiwa juga sangat dapat diperluas. Tim lain dapat memperluas fitur dan menambahkan fungsionalitas tanpa memengaruhi layanan mikro yang ada. Dengan memublikasikan peristiwa, aplikasi dapat berintegrasi dengan sistem yang ada—dan aplikasi masa depan dapat berintegrasi dengan mudah sebagai konsumen peristiwa—tanpa mengubah solusi yang ada.
Produsen peristiwa tidak memiliki pengetahuan mengenai konsumen peristiwa, sehingga memperluas sistem memiliki lebih sedikit gesekan, dan fitur atau integrasi baru tidak menambah ketergantungan yang memperlambat pengembangan di masa mendatang.
Mengurangi kompleksitas
Layanan mikro memungkinkan developer dan arsitek untuk menguraikan alur kerja yang kompleks. Misalnya, layanan mikro dapat memecah monolit perdagangan elektronik menjadi penerimaan pesanan dan proses pembayaran dengan layanan inventaris, pemenuhan, dan akuntansi yang terpisah.
Beban kerja yang mungkin rumit untuk dikelola dan diatur dalam monolit menjadi serangkaian layanan sederhana yang dipisahkan dan dikelola secara independen dan berkomunikasi secara asinkron melalui pesan peristiwa.
Pendekatan yang didorong peristiwa memungkinkan untuk merakit dan mengatur layanan yang memproses data dengan kecepatan berbeda. Dalam contoh berikut, layanan mikro penerimaan pesanan berinteraksi dengan sistem pemrosesan pembayaran melalui antrean.
Dalam contoh, layanan penerimaan pesanan dapat menyimpan pesanan masuk dalam jumlah besar dengan menyangga pesan dalam antrean.
Layanan pemrosesan pembayaran, yang biasanya lebih lambat karena kerumitan penanganan pembayaran, dapat menerima aliran pesan yang stabil dari antrean. Transisi layanan pembayaran antara berbagai status sistem karena coba lagi dan logika penanganan kesalahan. Layanan alur kerja mengatur dan mengelola langkah pembayaran berdasarkan status sistem, dan pada akhirnya menghasilkan lebih banyak peristiwa yang menarik untuk layanan Inventaris, Pemenuhan, dan Akuntansi.
Mengaudit dengan mudah
Router peristiwa dalam arsitektur yang didorong peristiwa bertindak sebagai lokasi terpusat untuk mengaudit aplikasi Anda dan menentukan kebijakan. Kebijakan ini dapat membatasi pengguna yang dapat memublikasikan dan berlangganan router, serta mengontrol pengguna dan sumber daya yang memiliki izin untuk mengakses data Anda. Anda juga dapat mengenkripsi peristiwa bergerak dan diam.
Memangkas biaya
EDA berbasis push, sehingga semuanya terjadi sesuai permintaan saat peristiwa muncul dengan sendirinya di router. Dengan demikian, Anda tidak membayar polling berkelanjutan untuk memeriksa peristiwa. Hal ini berarti lebih sedikit konsumsi bandwidth jaringan, lebih sedikit penggunaan CPU, lebih sedikit kapasitas armada yang diam, dan lebih sedikit jabat tangan SSL/TLS.
Bagaimana Arsitektur yang Didorong Peristiwa (EDA) bekerja?
Berikut contoh arsitektur yang didorong peristiwa (EDA) untuk sebuah situs perdagangan elektronik:
%20for%20an%20ecommerce%20site.88b2240905b1b6addd672871b98bcb17bd44d701.jpg)
Situs contoh ini menunjukkan tiga komponen utama produsen peristiwa dan peristiwa yang mereka hasilkan. Dalam skenario ini, Router Peristiwa menyerap dan memfilter peristiwa, lalu mengirimkan satu atau beberapa peristiwa ke Konsumen Peristiwa.
Arsitektur yang didorong peristiwa memungkinkan situs untuk bereaksi terhadap perubahan dari berbagai sumber selama masa permintaan puncak, tanpa merusak aplikasi atau menyediakan sumber daya yang berlebihan.
Tipe beban kerja apa yang cocok untuk arsitektur yang didorong peristiwa (EDA)?
Arsitektur yang didorong peristiwa (EDA) dapat memberikan cara yang efektif untuk memenuhi tuntutan beban kerja yang dapat diskalakan dan tersedia dengan sangat baik. EDA juga berlaku untuk beban kerja dengan pola lalu lintas yang tidak dapat diprediksi atau “meruncing”.
Bagaimana cara arsitektur yang didorong peristiwa (EDA) meningkatkan aplikasi?
Arsitektur yang didorong peristiwa (EDA) mempromosikan penggabungan longgar antar komponen, menjadikannya pendekatan yang baik untuk membangun aplikasi terdistribusi yang modern.
Produsen peristiwa tidak menyadari, tidak peduli, dan tidak terbebani oleh aktivitas konsumen hilir dari peristiwa yang mereka hasilkan. Peristiwa itu sendiri mewakili perubahan dalam keadaan dan mungkin atau tidak berisi data. Peristiwa tidak menyadari konsekuensi dari keberadaannya. Konsumen mendengarkan dan memproses peristiwa yang menarik. Anda dapat membawa konsumen baru secara online untuk menyediakan fungsionalitas baru tanpa mengganggu alur kerja yang ada.
EDA mempromosikan dekomposisi sistem monolitik menjadi model domain yang lebih kecil. Developer dapat mempercepat dengan beban kognitif yang lebih sedikit sehingga menjadi lebih cepat dan produktif. Saat fungsi penting dipisahkan, risiko untuk melakukan deployment pembaruan dan fitur baru juga lebih kecil.
Apa saja kasus penggunaan dalam arsitektur yang didorong peristiwa (EDA)?
Komunikasi layanan mikro untuk web dan backend seluler
Situs web ritel atau media dan hiburan sering kali harus dinaikkan skalanya untuk menangani lalu lintas yang tidak terduga. Pelanggan mengunjungi situs web perdagangan elektronik dan melakukan pemesanan. Peristiwa pemesanan dikirim ke router peristiwa. Semua layanan mikro hilir dapat mengambil peristiwa pemesanan untuk diproses. Contoh tindakan dapat mencakup: mengirim pesanan, mengotorisasi pembayaran, dan mengirimkan detail pesanan ke penyedia pengiriman.
Karena masing-masing layanan mikro dapat diskalakan dan gagal secara independen, proses dapat dinaikkan skalanya selama periode pesanan puncak tanpa satu titik kegagalan.
Otomatisasi alur kerja bisnis
Banyak alur kerja bisnis, seperti transaksi jasa keuangan, memerlukan pengulangan langkah yang sama. Anda dapat memulai dan mengotomatiskan langkah-langkah tersebut dengan arsitektur yang didorong peristiwa (EDA).
Misalnya, saat nasabah mengajukan rekening baru di bank, bank tersebut harus melakukan beberapa pemeriksaan data (dokumen identitas, alamat, dll). Beberapa akun juga memerlukan tahap persetujuan manusia. Anda dapat mengatur semua langkah ini melalui layanan alur kerja yang menjalankan langkah-langkah secara otomatis saat aplikasi akun baru diterima.
Anda juga dapat menambahkan alur kerja untuk memproses data aplikasi pelanggan secara asinkron dengan machine learning untuk mengekstrak data yang relevan, yang berpotensi menghemat waktu pengumpulan dan validasi data manual.
Integrasi aplikasi SaaS
Tantangan utama untuk lingkungan perangkat lunak sebagai layanan (SaaS) adalah kurangnya visibilitas ke dalam aktivitas dan data pengguna. Untuk membuka kunci data tersembunyi, arsitektur yang didorong peristiwa dapat menyerap peristiwa aplikasi SaaS atau mengirim peristiwa ke aplikasi SaaS mereka. Misalnya, Anda dapat membangun perangkat lunak perantara (middleware) untuk menyerap data pesanan partner yang masuk dan mengirim pesanan langsung ke aplikasi pemrosesan pesanan internal.
Otomatisasi infrastruktur
Saat menjalankan beban kerja intensif komputasi (seperti analisis keuangan, penelitian genomik, atau transkode media), Anda dapat meminta sumber daya komputasi merespons dengan cara menaikkan skala untuk pemrosesan yang sangat paralel, lalu menurunkan skala setelah tugas selesai.
Misalnya, dalam industri yang diatur dengan sangat ketat, perusahaan dengan EDA dapat meningkatkan sumber daya postur keamanan sebagai respons terhadap insiden, atau mengambil tindakan perbaikan setiap kali kebijakan keamanan mengirimkan peristiwa peringatan.
Kapan sebaiknya Anda menggunakan arsitektur yang didorong peristiwa (EDA)?
Arsitektur yang didorong peristiwa (EDA) ideal untuk meningkatkan ketangkasan dan bergerak cepat. Arsitektur ini lazim ditemukan di aplikasi modern yang menggunakan layanan mikro, atau setiap aplikasi yang memiliki komponen terpisah.
Integrasi sistem heterogen
Jika Anda memiliki sistem yang berjalan di tumpukan berbeda, Anda dapat menggunakan EDA untuk berbagi informasi antartumpukan tanpa pemisahan. Router peristiwa menetapkan prosedur tidak langsung dan interoperabilitas di antara sistem, sehingga dapat bertukar pesan dan data sembari tetap agnostik.
Replikasi data lintas wilayah dan lintas akun
Anda dapat menggunakan EDA untuk mengoordinasikan sistem di antara berbagai tim yang beroperasi dan melakukan deployment di berbagai wilayah dan akun AWS berbeda. Dengan menggunakan router 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 EDA 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 masih banyak lagi.
Penyebarluasan dan pemrosesan paralel
Jika Anda memiliki banyak sistem yang perlu beroperasi untuk merespons peristiwa, Anda dapat menggunakan EDA untuk menyebarluaskan peristiwa tanpa perlu menulis kode kustom untuk mendorong ke setiap konsumen. Router ini akan mendorong peristiwa ke sistem. Masing-masing router dapat memproses peristiwa secara paralel dengan tujuan berbeda.
Apa pola umum yang ada pada arsitektur yang didorong peristiwa (EDA)?
Banyak fungsi pendek
Membuat banyak fungsi pendek dibandingkan fungsi yang lebih besar. Membuat fungsi yang sangat khusus untuk beban kerja Anda berarti fungsi tersebut ringkas dan umumnya mengurangi waktu pemrosesan. Setiap fungsi harus menangani peristiwa yang diteruskan ke fungsi, tanpa pengetahuan atau ekspektasi dari keseluruhan alur kerja atau volume transaksi. Hal ini menjadikan fungsi agnostik bagi sumber peristiwa dengan sambungan minimal ke layanan lain.
Pemrosesan sesuai permintaan alih-alih batch
Banyak sistem tradisional didesain untuk beroperasi secara berkala dan memproses kumpulan transaksi yang menumpuk seiring waktu. Misalnya, aplikasi perbankan mungkin berjalan setiap jam untuk memproses transaksi ATM menjadi buku besar pusat.
Dalam arsitektur yang didorong peristiwa (EDA), pemrosesan kustom dapat merespons setiap peristiwa. Hal ini memungkinkan layanan untuk menaikkan skala konkurensi yang diperlukan untuk memproses transaksi dalam waktu dekat.
Pemulihan gangguan
Dalam kasus gangguan, layanan mungkin secara otomatis dipanggil untuk mencoba lagi memproses suatu peristiwa. Karena layanan mungkin menerima peristiwa yang sama lebih dari sekali, desain berfungsi sebagai idempoten. Hal ini memastikan bahwa hasilnya tidak berubah setelah pertama kali layanan menerima peristiwa.
Misalnya, jika pengecer mencoba memproses kartu kredit dua kali karena percobaan ulang, layanan memproses pembayaran hanya pada upaya pertama. Pada percobaan ulang, layanan memverifikasi status pembayaran dan membuang peristiwa tersebut.
Apa saja tantangan dalam arsitektur yang didorong peristiwa (EDA)?
Saat mengadopsi arsitektur yang didorong peristiwa (EDA), Anda mungkin perlu memikirkan kembali cara Anda melihat desain aplikasi.
Latensi variabel
Tidak seperti aplikasi monolitik, yang dapat memproses semuanya dalam ruang memori yang sama pada satu perangkat, aplikasi yang didorong peristiwa berkomunikasi melalui jaringan. Desain ini memperkenalkan latensi variabel. Meskipun aplikasi monolitik mungkin memiliki latensi variabel yang lebih rendah atau lebih sedikit, ini umumnya mengorbankan skalabilitas dan ketersediaan.
Layanan AWS nirserver tersedia dengan sangat baik, artinya layanan tersebut beroperasi di lebih dari satu Zona Ketersediaan di Wilayah AWS. Jika terjadi gangguan layanan, layanan secara otomatis dialihkan ke Zona Ketersediaan alternatif dan mencoba lagi transaksi. Akibatnya, alih-alih gagal, transaksi mungkin berhasil diselesaikan tetapi dengan latensi yang lebih tinggi.
Beban kerja yang membutuhkan performa latensi rendah yang konsisten bukanlah kandidat yang baik untuk EDA. Dua contohnya adalah aplikasi perdagangan berfrekuensi tinggi di bank atau otomatisasi robotika submilidetik di gudang.
Konsistensi akhir
Suatu peristiwa mewakili perubahan keadaan. Dengan banyaknya peristiwa yang mengalir melalui layanan yang berbeda dalam arsitektur pada titik waktu tertentu, beban kerja seperti itu seringkali konsisten pada akhirnya. Hal ini membuatnya lebih kompleks untuk memproses transaksi, menangani duplikat, atau menentukan keadaan sistem secara keseluruhan.
Beberapa beban kerja tidak cocok untuk EDA karena kebutuhan akan properti ACID. Namun, banyak beban kerja berisi kombinasi persyaratan yang pada akhirnya konsisten (misalnya, total pesanan pada jam saat ini) atau sangat konsisten (misalnya, inventaris saat ini). Untuk fitur-fitur yang membutuhkan konsistensi data yang kuat, ada pola arsitektur untuk mendukungnya. Misalnya:
- DynamoDB dapat memberikan bacaan sangat konsisten, terkadang pada latensi yang lebih tinggi, dan juga dapat mendukung transaksi untuk membantu menjaga konsistensi data.
- Anda dapat menggunakan basis data relasional untuk fitur yang memerlukan properti ACID, meskipun basis data relasional kurang dapat diskalakan daripada penyimpanan data NoSQL.
Mengembalikan nilai ke pemanggil
Dalam banyak kasus, aplikasi yang didorong peristiwa adalah asinkron. Artinya, layanan pemanggil tidak menunggu permintaan dari layanan lain sebelum melanjutkan pekerjaan lain. Karakteristik mendasar dari EDA ini memungkinkan skalabilitas dan fleksibilitas; namun, hal itu membuat nilai balik yang lewat atau hasil alur kerja lebih kompleks daripada arus sinkron.
Dalam banyak kasus, mengembalikan nilai kurang penting daripada memastikan keberhasilan atau kegagalan pemrosesan peristiwa. Fitur yang memastikan pemrosesan peristiwa mungkin lebih penting daripada mengembalikan nilai ke pemanggil.
Untuk beban kerja interaktif, seperti aplikasi web dan seluler, pengguna akhir biasanya mengharapkan untuk menerima nilai balik atau status transaksi saat ini. Untuk beban kerja ini, ada beberapa pola desain yang dapat memberikan eventing kaya kembali ke pemanggil. Namun, implementasi dalam arsitektur yang didorong peristiwa ini lebih kompleks daripada menggunakan nilai pengembalian asinkron tradisional. Platform seringkali dapat mengurangi kompleksitas ini.
Debugging di seluruh layanan dan fungsi
Debugging sistem yang didorong peristiwa berbeda dengan debugging aplikasi monolitik. Seperti halnya semua aplikasi berbasis layanan mikro dan berbagai sistem dan layanan yang melewati peristiwa, mencatat dan memproduksi ulang keadaan yang tepat dari beberapa layanan dapat menjadi tantangan saat terjadi kesalahan. Karena setiap pemanggilan layanan dan fungsi memiliki file log yang terpisah, dapat menjadi lebih rumit untuk menentukan apa yang terjadi pada peristiwa tertentu yang menyebabkan kesalahan.
Orkestrasi
Alur kerja sederhana menjadi lebih kompleks dari waktu ke waktu adalah hal yang biasa. Dalam monolit yang khusus, perubahan ini dapat menghasilkan grup fungsi dan layanan yang lebih erat, serta perutean dan pengecualian penanganan kode yang kompleks.
Untuk melacak status sistem, alur kerja yang melibatkan logika percabangan, berbagai tipe model kegagalan, dan logika coba ulang biasanya menggunakan orkestrator. Saat membuat aplikasi nirserver yang didorong peristiwa, penting untuk mengidentifikasi waktu terjadinya sehingga Anda dapat memigrasikan logika ini ke mesin status untuk orkestrasi yang tepat.
Layanan AWS mana yang menggunakan arsitektur yang didorong peristiwa (EDA)?
Layanan AWS biasanya menghasilkan atau menggunakan peristiwa, sehingga memudahkan dalam membangun solusi dengan arsitektur yang didorong peristiwa (EDA).
Selain itu, layanan seperti Amazon EventBridge, Amazon SNS, Amazon SQS, dan AWS Step Functions menyertakan fitur yang membantu pelanggan menulis lebih sedikit kode boilerplate dan membuat EDA lebih cepat.
Amazon EventBridge
Anda dapat menggunakan Amazon EventBridge untuk membangun bus peristiwa untuk aplikasi yang didorong peristiwa dalam skala besar dan menggunakan peristiwa dari aplikasi SaaS, layanan AWS lain, atau aplikasi khusus.
EventBridge menerapkan aturan untuk merutekan peristiwa dari sumber peristiwa ke target yang berbeda. Target dapat mencakup layanan AWS seperti AWS Lambda, Step Functions, dan Amazon Kinesis, atau setiap titik akhir HTTP melalui tujuan API EventBridge.
Integrasi populer untuk kasus penggunaan EDA adalah Step Functions, yang di dalamnya peristiwa memicu alur kerja tertentu.
AWS Step Functions
AWS Step Functions mencakup Workflow Studio, sebuah desainer alur kerja visual kode rendah yang digunakan builder untuk mengatur berbagai layanan AWS. Anda dapat menggunakan Workflow Studio untuk membangun aplikasi terdistribusi, mengotomatiskan proses IT dan bisnis, serta membangun alur data dan machine learning menggunakan layanan AWS.
Amazon SNS
Kami menyarankan penggunaan Amazon Simple Notification Service (Amazon SNS) untuk membangun aplikasi yang bereaksi terhadap peristiwa throughput tinggi dan berlatensi rendah yang diterbitkan oleh aplikasi, layanan mikro, atau layanan AWS lainnya. Anda juga dapat menggunakan Amazon SNS untuk aplikasi yang membutuhkan fanout yang sangat tinggi hingga ribuan atau bahkan jutaan titik akhir.
Amazon SQS
Amazon Simple Queue Service (Amazon SQS) menawarkan layanan antrean host yang aman, tahan lama, dan tersedia yang dapat Anda gunakan untuk mengintegrasikan dan memisahkan sistem dan komponen perangkat lunak terdistribusi. Amazon SQS menawarkan konstruksi umum seperti antrean surat mati dan tanda alokasi biaya.
Langkah berikutnya Arsitektur yang Didorong Peristiwa AWS
