Dunia tidak tinggal diam. Kemajuan menciptakan tantangan teknologi baru. Sesuai dengan perubahan kebutuhan, arsitektur sistem informasi harus berkembang. Hari ini kita akan berbicara tentang arsitektur berbasis peristiwa, konkurensi, konkurensi, asinkroni, dan bagaimana Anda dapat hidup damai dengan semua ini di Erlang.
pengenalan
Bergantung pada ukuran sistem yang dirancang dan persyaratannya, kami, para pengembang, memilih metode pertukaran informasi dalam sistem. Dalam kebanyakan kasus, untuk mengatur interaksi layanan, opsi yang berfungsi mungkin berupa skema dengan broker, misalnya, berdasarkan RabbitMQ atau kafka. Namun terkadang alur peristiwa, SLA, dan tingkat kendali atas sistem sedemikian rupa sehingga pesan siap pakai tidak cocok untuk kami. Tentu saja, Anda dapat sedikit memperumit sistem dengan mengambil tanggung jawab atas lapisan transport dan pembentukan cluster, misalnya menggunakan ZeroMQ atau nanomsg. Namun jika sistem memiliki throughput dan kemampuan yang cukup untuk klaster Erlang standar, maka masalah pengenalan entitas tambahan memerlukan studi terperinci dan pembenaran ekonomi.
Topik aplikasi terdistribusi reaktif cukup luas. Agar tetap sesuai dengan format artikel, subjek diskusi hari ini hanya akan berupa lingkungan homogen yang dibangun di Erlang/Elixir. Ekosistem Erlang/OTP memungkinkan Anda menerapkan arsitektur reaktif dengan sedikit usaha. Namun bagaimanapun juga, kita memerlukan lapisan perpesanan.
Landasan teori
Desain dimulai dengan menentukan tujuan dan batasan. Tujuan utamanya bukan pada bidang pembangunan demi pembangunan. Kita perlu mendapatkan alat yang aman dan terukur yang menjadi dasar kita dapat membuat dan, yang paling penting, mengembangkan aplikasi modern di berbagai tingkatan: mulai dari aplikasi server tunggal yang melayani audiens kecil, yang nantinya dapat berkembang menjadi cluster hingga 50 orang. -60 node, diakhiri dengan federasi cluster. Jadi, tujuan utamanya adalah memaksimalkan keuntungan dengan mengurangi biaya pengembangan dan kepemilikan sistem akhir.
Mari kita soroti 4 persyaratan utama untuk sistem akhir:
- Π‘berorientasi pada peristiwa.
Sistem selalu siap untuk melewati alur peristiwa dan melakukan tindakan yang diperlukan; - Πskalabilitas.
Blok individual dapat diskalakan baik secara vertikal maupun horizontal. Keseluruhan sistem harus mampu mencapai pertumbuhan horizontal tanpa batas; - Πtoleransi kesalahan.
Semua tingkatan dan semua layanan harus dapat pulih secara otomatis dari kegagalan; - Πjaminan waktu respons.
Waktu sangat berharga dan pengguna tidak perlu menunggu terlalu lama.
Ingat dongeng lama tentang βMesin kecil yang bisaβ? Agar sistem yang dirancang berhasil keluar dari tahap prototipe dan menjadi progresif, landasannya harus memenuhi persyaratan minimum ASBUT.
Satu hal lagi yang ditambahkan ke perpesanan sebagai alat infrastruktur dan dasar untuk semua layanan: kemudahan penggunaan bagi pemrogram.
Berorientasi pada acara
Agar aplikasi dapat berkembang dari satu server ke cluster, arsitekturnya harus mendukung kopling longgar. Model asinkron memenuhi persyaratan ini. Di dalamnya, pengirim dan penerima peduli dengan muatan informasi pesan dan tidak khawatir tentang transmisi dan perutean dalam sistem.
Skalabilitas
Skalabilitas dan efisiensi sistem saling bersebelahan. Komponen aplikasi harus mampu memanfaatkan seluruh sumber daya yang ada. Semakin efisien kita memanfaatkan kapasitas dan semakin optimal metode pemrosesan kita, semakin sedikit uang yang kita keluarkan untuk peralatan.
Dalam satu mesin, Erlang menciptakan lingkungan yang sangat kompetitif. Keseimbangan antara konkurensi dan paralelisme dapat diatur dengan memilih jumlah thread sistem operasi yang tersedia untuk Erlang VM dan jumlah penjadwal yang menggunakan thread ini.
Proses Erlang tidak berbagi status dan beroperasi dalam mode non-pemblokiran. Ini memberikan latensi yang relatif rendah dan throughput yang lebih tinggi dibandingkan aplikasi berbasis pemblokiran tradisional. Penjadwal Erlang memastikan alokasi CPU dan IO yang adil, dan tidak adanya pemblokiran memungkinkan aplikasi merespons bahkan selama beban puncak atau kegagalan.
Di tingkat cluster, masalah pembuangan juga ada. Semua mesin di cluster harus dimuat secara merata dan jaringan tidak kelebihan beban. Mari kita bayangkan sebuah situasi: lalu lintas pengguna mendarat di penyeimbang masuk (haproxy, nginx, dll), mereka mendistribusikan permintaan pemrosesan secara merata di antara kumpulan backend yang tersedia. Dalam infrastruktur aplikasi, layanan yang mengimplementasikan antarmuka yang diperlukan hanya berada pada tahap terakhir dan perlu meminta sejumlah layanan lain untuk merespons permintaan awal. Permintaan internal juga memerlukan perutean dan penyeimbangan.
Untuk mengelola aliran data secara efektif, perpesanan harus menyediakan antarmuka bagi pengembang untuk mengelola perutean dan penyeimbangan beban. Berkat ini, pengembang akan dapat, menggunakan pola layanan mikro (agregator, proxy, rantai, cabang, dll), untuk memecahkan masalah standar dan masalah yang jarang muncul.
Dari sudut pandang bisnis, skalabilitas merupakan salah satu alat manajemen risiko. Hal utama adalah memenuhi permintaan pelanggan dengan menggunakan peralatan secara optimal:
- Ketika kekuatan peralatan meningkat sebagai akibat dari kemajuan. Itu tidak akan menganggur karena perangkat lunak yang tidak sempurna. Erlang berskala secara vertikal dengan baik dan akan selalu dapat memanfaatkan semua inti CPU dan memori yang tersedia;
- Di lingkungan cloud, kami dapat mengatur jumlah peralatan tergantung pada beban saat ini atau perkiraan dan menjamin SLA.
toleransi kesalahan
Mari kita pertimbangkan dua aksioma: βKegagalan tidak dapat diterimaβ dan βAkan selalu ada kegagalan.β Bagi sebuah bisnis, kegagalan perangkat lunak berarti kehilangan uang, dan yang lebih buruk lagi, hilangnya reputasi. Menyeimbangkan antara kemungkinan kerugian dan biaya pengembangan perangkat lunak yang toleran terhadap kesalahan, kompromi sering kali dapat ditemukan.
Dalam jangka pendek, arsitektur yang menggabungkan toleransi kesalahan menghemat uang untuk membeli solusi pengelompokan siap pakai. Harganya mahal dan juga memiliki bug.
Dalam jangka panjang, arsitektur yang toleran terhadap kesalahan akan memberikan keuntungan berkali-kali lipat di semua tahap pengembangan.
Pesan dalam basis kode memungkinkan Anda mengetahui secara detail interaksi komponen dalam sistem pada tahap pengembangan. Hal ini menyederhanakan tugas merespons dan mengelola kegagalan, karena semua komponen penting menangani kegagalan, dan sistem yang dihasilkan mengetahui cara secara otomatis kembali normal setelah kegagalan sesuai rencana.
Daya tanggap
Terlepas dari kegagalannya, aplikasi harus merespons permintaan dan memenuhi SLA. Kenyataannya adalah masyarakat tidak mau menunggu, sehingga dunia usaha harus beradaptasi. Semakin banyak aplikasi yang diharapkan memiliki respon yang tinggi.
Aplikasi responsif beroperasi hampir secara real-time. Erlang VM beroperasi dalam mode soft real-time. Untuk beberapa area, seperti perdagangan saham, obat-obatan, dan kontrol peralatan industri, mode hard real-time sangatlah penting.
Sistem responsif meningkatkan UX dan menguntungkan bisnis.
Ringkasan pendahuluan
Saat merencanakan artikel ini, saya ingin berbagi pengalaman saya dalam membuat broker perpesanan dan membangun sistem kompleks berdasarkan broker tersebut. Namun bagian teoritis dan motivasinya ternyata cukup luas.
Di bagian kedua artikel ini, saya akan membahas tentang nuansa penerapan titik pertukaran, pola pengiriman pesan, dan penerapannya.
Pada bagian ketiga kita akan mempertimbangkan masalah umum pengorganisasian layanan, perutean, dan penyeimbangan. Mari kita bicara tentang sisi praktis skalabilitas dan toleransi kesalahan sistem.
Akhir dari bagian pertama.
foto .
Sumber: www.habr.com