Sementara penjualan kami berlanjut untuk selera yang paling cerdas, kami mengalihkan perhatian Anda ke tema lain dari pencarian kreatif kami: Event-Driven Architecture (EDA). Di bawah potongan Anda akan menemukan diagram alur yang indah dan cerita tentang bagaimana paradigma inovatif ini membantu dalam pengembangan aplikasi web.
Artikel ini akan membahas beberapa tantangan yang mendorong inovasi dalam pengembangan web modern. Selanjutnya, kita akan mendalami Event-Driven Architecture (EDA), yang mengatasi masalah ini dengan mendefinisikan ulang arsitektur server.
Aplikasi web telah berkembang pesat sejak hari-hari ketika konten HTML statis disajikan dari server. Saat ini, aplikasi web telah menjadi jauh lebih kompleks, mereka menggunakan berbagai kerangka kerja, pusat data, dan teknologi. Dalam beberapa tahun terakhir, dua tren dapat dicatat yang menentukan perkembangan pasar TI:
- Mentransfer aplikasi ke cloud ;
- Implementasi arsitektur microservice .
Ide-ide ini sangat menentukan bagaimana perangkat lunak dirancang dan dibangun saat ini. Kita dapat mengatakan bahwa saat ini kita tidak lagi membangun aplikasi, tetapi platform. Aplikasi tidak lagi menggunakan ruang komputasi bersama. Sebaliknya, mereka harus bertukar informasi satu sama lain menggunakan protokol komunikasi ringan seperti REST API atau panggilan prosedur jarak jauh (RPC). Model ini telah menghasilkan produk hebat seperti Facebook, Netflix, Uber, dan banyak lagi.
Artikel ini akan membahas beberapa tantangan yang mendorong inovasi dalam pengembangan web modern. Selanjutnya, kita akan mendalami Event-Driven Architecture (EDA), yang mengatasi masalah ini dengan mendefinisikan ulang arsitektur server.
Masalah saat ini dari web modern
Teknologi web apa pun harus mengatasi tantangan yang harus dipenuhi oleh aplikasi asinkron multi-pengguna modern, yang dirancang untuk berjalan dengan lancar:
Ketersediaan
Sekarang kami bekerja bukan dengan satu aplikasi, tetapi dengan banyak - lusinan atau bahkan ratusan - layanan terkait, dan masing-masing harus menyelesaikan masalah mereka sepanjang waktu, tujuh hari seminggu. Bagaimana ini bisa dicapai? Paling sering, layanan diskalakan secara horizontal ke beberapa instance yang dapat didistribusikan ke beberapa pusat data untuk memastikan ketersediaan yang tinggi. Semua permintaan untuk layanan khusus ini dirutekan dan didistribusikan secara merata di semua contoh. Beberapa alat penerapan menyediakan kemampuan pemulihan mandiri, jadi jika satu contoh gagal, yang lain dibuat untuk menggantikannya.
Skalabilitas
Skalabilitas dalam banyak hal mirip dengan ketersediaan. Inti dari aksesibilitas adalah untuk memastikan bahwa setidaknya satu contoh layanan aktif dan berjalan, siap untuk melayani permintaan yang masuk. Skalabilitas, pada gilirannya, terutama terkait dengan kinerja. Jika aplikasi kelebihan beban, contoh baru dari aplikasi itu dibuat untuk mengakomodasi peningkatan jumlah permintaan. Tetapi penskalaan aplikasi secara vertikal bukanlah tugas yang sepele, terutama jika menyangkut aplikasi berstatus .
Satu sumber kebenaran
Sebelum munculnya layanan mikro, ini adalah tugas yang cukup sederhana. Semua data terletak di satu lokasi, sebagai aturan, itu adalah database relasional satu atau lain. Namun, ketika beberapa layanan berbagi database, masalah seperti ketergantungan antara tim yang berbeda terkait perubahan skema atau masalah kinerja dapat dibuat. Biasanya masalah ini diselesaikan dengan mengalokasikan database-nya sendiri untuk setiap layanan. Sumber kebenaran terdistribusi sangat membantu dalam memelihara arsitektur yang bersih, tetapi dalam situasi seperti ini Anda harus berurusan dengan transaksi terdistribusi dan kerumitan dalam mendukung banyak database.
Sinkronisasi
Dalam skenario respons permintaan yang khas, klien menunggu server merespons; itu memblokir semua tindakan sampai menerima tanggapan, atau sampai penundaan yang ditentukan berakhir. Jika Anda mengambil perilaku ini dan menerapkannya ke dalam arsitektur layanan mikro menggunakan rantai panggilan yang dijalankan melalui seluruh sistem, Anda dapat dengan mudah berakhir di apa yang disebut "neraka layanan mikro". Semuanya dimulai dengan memanggil hanya satu layanan, sebut saja "layanan A". Tetapi kemudian layanan A harus memanggil layanan B, dan kesenangan dimulai. Masalah dengan perilaku ini adalah ini: jika layanan itu sendiri dikaitkan dengan sumber daya yang diblokir (misalnya, utas macet), penundaan bertambah secara eksponensial. Jika kami mengizinkan penundaan 500 md per layanan, dan ada lima panggilan layanan dalam rantai, maka layanan pertama akan membutuhkan penundaan 2.500 md (2,5 detik), dan yang terakhir - 500 md.
Tantangan web modern
Pengantar arsitektur berbasis peristiwa
Event-Driven Architecture (EDA) adalah paradigma arsitektur perangkat lunak yang memfasilitasi pembuatan, penemuan, konsumsi peristiwa, dan respons terhadapnya.
Dalam aplikasi tiga tingkat klasik, inti dari sistem adalah database. Dalam EDA, fokus bergeser ke acara dan bagaimana mereka memfilter melalui sistem. Pergeseran fokus ini memungkinkan perubahan total dalam pendekatan desain aplikasi dan pemecahan masalah yang disebutkan di atas.
Sebelum melihat secara tepat bagaimana hal ini dilakukan di EDA, mari kita lihat apa itu "peristiwa". Peristiwa adalah tindakan yang memulai beberapa pemberitahuan atau perubahan status aplikasi. Lampu menyala (pemberitahuan), termostat mematikan sistem pemanas (pemberitahuan), pengguna mengubah alamat mereka (perubahan negara), salah satu teman Anda mengubah nomor telepon mereka (perubahan negara). Ini semua adalah peristiwa, tetapi belum menjadi fakta bahwa kita harus menambahkannya ke solusi yang digerakkan oleh peristiwa. Diasumsikan bahwa hanya peristiwa yang relevan dengan bisnis yang ditambahkan ke arsitektur. Peristiwa "pengguna memesan" penting dari sudut pandang bisnis, tetapi "pengguna makan pizza atau makan siang yang dipesan" tidak.
Jika Anda memikirkan tentang beberapa peristiwa, maka tentang beberapa peristiwa akan segera jelas bahwa peristiwa itu penting untuk bisnis, dan tentang beberapa - tidak. Terutama tentang yang terjadi sebagai respons terhadap peristiwa lain. Teknik yang disebut " serangan peristiwa " digunakan untuk mengidentifikasi peristiwa yang melewati sistem . Peserta dalam pengembangan aplikasi (dari programmer hingga pengembang logika bisnis dan ahli materi pelajaran) berkumpul dan bersama-sama memetakan semua proses bisnis, menyajikannya dalam bentuk acara tertentu. Apabila peta tersebut sudah siap maka hasil pekerjaan dirumuskan dalam bentuk kebutuhan yang harus dipenuhi pada saat mengembangkan aplikasi.
Contoh aplikasi untuk pemesanan yang dijelaskan dengan metode serangan peristiwa
Setelah mengidentifikasi peristiwa yang menarik bagi kami dan memutuskan cara mengidentifikasinya, mari kita lihat bagaimana paradigma ini dapat menyelesaikan masalah khas yang disebutkan di atas.
Alur peristiwa searah: dari produsen ke konsumen. Bandingkan situasi ini dengan panggilan REST. Produser acara pada prinsipnya tidak mengharapkan respons dari konsumen, sedangkan dalam kasus panggilan REST, akan selalu ada respons. Tidak ada respons berarti tidak perlu memblokir eksekusi kode hingga terjadi hal lain. Dalam hal ini, peristiwa menjadi tidak sinkron , yang sepenuhnya menghilangkan risiko macet dalam penundaan.
Peristiwa terjadi sebagai akibat dari suatu tindakan, jadi tidak ada sistem target; layanan A tidak dapat dikatakan memicu peristiwa pada layanan B; tetapi kita dapat mengatakan bahwa layanan B tertarik pada peristiwa yang dihasilkan oleh layanan A. Benar, mungkin ada "pihak yang berkepentingan" lain dalam sistem ini, misalnya, layanan C atau D.
Bagaimana kita bisa memastikan bahwa peristiwa yang dimulai dalam sistem tertentu akan menjangkau semua Layanan "tertarik"? Biasanya, sistem semacam itu diselesaikan menggunakan makelar pesan. Broker hanyalah sebuah aplikasi yang bertindak sebagai perantara antara emitor acara (aplikasi yang menghasilkan acara) dan konsumen acara. Dengan demikian, aplikasi dapat dipisahkan satu sama lain dengan rapi, menangani masalah aksesibilitas, yang telah dibahas di atas dalam posting ini. Jika aplikasi tidak tersedia saat ini, maka, kembali online, aplikasi akan mulai menggunakan peristiwa dan memprosesnya, menggantikan semua peristiwa yang telah terjadi selama periode sementara tidak tersedia.
Bagaimana dengan gudang data? Bisakah acara disimpan dalam database, atau ada hal lain yang diperlukan selain database? Tentu saja, peristiwa dapat disimpan dalam database, tetapi dalam hal ini esensi "peristiwa" mereka hilang. Setelah peristiwa terjadi, kami tidak dapat lagi memperbaikinya, oleh karena itu peristiwa secara inheren tidak dapat diubah. Database, pada gilirannya ... dapat diubah, setelah memasukkan data ke dalam database, mereka dapat diubah.
Lebih baik menyimpan acara di log acara . Log acara tidak lebih dari terpusatgudang data, di mana setiap peristiwa dicatat sebagai urutan catatan yang tidak dapat diubah, yang disebut "log". Log dapat dibandingkan dengan log, di mana setiap peristiwa baru ditambahkan ke akhir daftar. Anda selalu dapat membuat ulang status terbaru dengan memutar ulang semua peristiwa log dari awal hingga saat ini.
Jadi, kami telah membahas semuanya kecuali skalabilitas. Layanan berbasis peristiwa selalu dirancang untuk diterapkan di banyak contoh. Karena keadaan seperti itu disimpan dalam log peristiwa, layanan itu sendiri akan menjadi tanpa kewarganegaraan, yang memungkinkan penskalaan yang akurat secara operasi dari setiap layanan yang diminati.
Satu-satunya pengecualian untuk prinsip ini adalah layanan yang dirancang untuk membuat tampilan terwujud.... Intinya, pandangan yang terwujud adalah keadaan yang menggambarkan log peristiwa pada titik waktu tertentu. Pendekatan ini digunakan untuk mempermudah kueri data. Kembali ke masalah penskalaan, tampilan yang terwujud hanyalah tampilan agregat dari peristiwa yang menyerupai tabel; tapi di mana kita menyimpan tabel ini? Paling sering, Anda melihat agregasi seperti itu dalam memori, dan pada saat yang sama layanan kami secara otomatis berubah menjadi yang stateful. Solusi cepat dan mudah adalah menyediakan database lokal untuk setiap layanan yang menciptakan tampilan terwujud. Dengan cara ini negara disimpan dalam database dan layanan berjalan tanpa kewarganegaraan.
Meskipun arsitektur yang digerakkan oleh peristiwa telah ada selama lebih dari 15 tahun, namun baru-baru ini ia mendapatkan popularitas yang serius, dan ini bukan kebetulan. Sebagian besar perusahaan sedang melalui tahap " transformasi digital " yang disertai dengan tuntutan liar. Karena kompleksitas persyaratan ini, para insinyur harus menguasai pendekatan baru untuk desain perangkat lunak, yang secara khusus menyiratkan, melemahkan penggabungan layanan satu sama lain dan mengurangi biaya pemeliharaan layanan. EDA adalah salah satu solusi yang mungkin untuk masalah ini, tetapi bukan satu-satunya. Selain itu, jangan berharap semua masalah akan teratasi, Anda hanya perlu beralih ke EDA. Beberapa fitur mungkin masih memerlukan REST API atau penyimpanan database yang kuat dan kuno. Pilih salah satu yang paling sesuai untuk Anda dan rancang dengan benar!