Dunia tidak tinggal diam. Kemajuan menciptakan tantangan teknologi baru. Sesuai dengan perubahan persyaratan, arsitektur sistem informasi juga harus berkembang. Hari ini kita akan berbicara tentang arsitektur berorientasi peristiwa, daya saing, konkurensi, asinkron, dan bagaimana hidup damai dengan semua ini di Erlang.
Pendahuluan
Tergantung pada ukuran sistem yang dirancang dan persyaratan untuk itu, kami, para pengembang, memilih metode pertukaran informasi dalam sistem. Dalam kebanyakan kasus, untuk mengatur interaksi layanan, opsi kerja dapat berupa skema dengan broker, misalnya, berdasarkan pada RabbitMQ atau kafka. Tetapi kadang-kadang aliran acara, SLA dan tingkat kontrol atas sistem sedemikian rupa sehingga pesan siap tidak cocok untuk kita. Tentu saja, Anda dapat menyulitkan sistem sedikit dengan mengambil tanggung jawab untuk lapisan transport dan pembentukan cluster, misalnya menggunakan ZeroMQ atau nanomsg. Tetapi jika sistem memiliki bandwidth yang cukup dan kemampuan cluster Erlang standar, maka masalah memperkenalkan entitas tambahan memerlukan studi rinci dan justifikasi ekonomi.
Topik aplikasi terdistribusi reaktif cukup luas. Untuk tetap dalam format artikel, subjek diskusi hari ini hanya lingkungan yang homogen yang dibangun berdasarkan Erlang / Elixir. Ekosistem Erlang / OTP memungkinkan arsitektur reaktif berbiaya rendah. Tetapi bagaimanapun juga, kita membutuhkan lapisan pesan.
Dasar teoretis
Desain dimulai dengan definisi tujuan dan batasan. Tujuan utamanya bukan dalam pengembangan untuk pembangunan. Kita perlu mendapatkan alat yang aman dan dapat diskalakan atas dasar yang dapat kita buat, dan yang paling penting, mengembangkan aplikasi modern di berbagai tingkatan: mulai dari server tunggal yang melayani audiens kecil, yang nantinya dapat berkembang menjadi cluster hingga 50-60 node, diakhiri dengan federasi cluster. Dengan demikian, tujuan utama adalah untuk memaksimalkan keuntungan dengan mengurangi biaya pengembangan dan kepemilikan sistem akhir.
Ada 4 persyaratan utama untuk sistem akhir:
- Dengan orientasi sehari-hari.
Sistem selalu siap untuk melewati sendiri serangkaian peristiwa dan melakukan tindakan yang diperlukan; - Skalabilitas.
Blok individual dapat diskalakan secara vertikal dan horizontal. Seluruh sistem harus mampu mencapai pertumbuhan horizontal yang tak terbatas; - Tentang toleransi kesalahan.
Semua level dan semua layanan harus dapat pulih secara otomatis dari kegagalan; - Dijamin waktu respons.
Waktu sangat berharga dan pengguna tidak harus menunggu terlalu lama.
Ingat dongeng tua tentang "Mesin kecil yang bisa", alias "Mesin yang bisa"? Agar sistem yang dirancang berhasil muncul dari tahap prototipe dan menjadi progresif, fondasinya harus memenuhi persyaratan minimum SMOG .
Hal lain ditambahkan ke olahpesan sebagai alat infrastruktur dan dasar untuk semua layanan: kegunaan untuk programmer.
Orientasi Acara
Agar aplikasi tumbuh dari satu server ke sebuah cluster, arsitekturnya harus memberikan konektivitas yang lemah. Model asinkron memenuhi persyaratan ini. Di dalamnya, pengirim dan penerima menangani beban informasi pesan dan tidak khawatir tentang transmisi dan perutean dalam sistem.
Skalabilitas
Skalabilitas dan kinerja sistem berdiri berdampingan. Komponen aplikasi harus dapat memanfaatkan semua sumber daya yang tersedia. Semakin efisien kita dapat memanfaatkan kapasitas dan semakin optimal metode pemrosesan kita, semakin sedikit kita menghabiskan uang untuk peralatan.
Erlang menciptakan lingkungan yang sangat kompetitif dalam satu mesin. Keseimbangan antara konkurensi dan konkurensi dapat diatur dengan memilih jumlah utas sistem operasi yang tersedia untuk Erlang VM dan jumlah penjadwal yang memanfaatkan utas ini.
Proses Erlang tidak memiliki keadaan umum dan bekerja dalam mode non-blocking. Ini memberikan latensi yang relatif rendah dan bandwidth yang lebih tinggi daripada aplikasi tradisional yang dibangun di atas pemblokiran sinkronisasi. Penjadwal Erlang menangani distribusi CPU dan IO yang adil, dan tidak adanya kunci memungkinkan aplikasi untuk merespons bahkan dalam beban puncak atau kegagalan.
Di tingkat cluster, masalah daur ulang juga ada. Penting bahwa semua mesin di kluster dimuat secara merata dan jaringan tidak kelebihan beban. Bayangkan sebuah situasi: lalu lintas pengguna mendarat di balancers yang masuk (haproxy, nginx, dll), mereka mendistribusikan permintaan pemrosesan secara merata antara set backend yang tersedia. Dalam kerangka infrastruktur aplikasi, layanan yang mengimplementasikan antarmuka yang diperlukan hanya satu mil terakhir, dan perlu meminta sejumlah layanan lain untuk menjawab permintaan awal. Kueri internal juga memerlukan perutean dan penyeimbangan.
Untuk mengelola aliran data secara efektif, olahpesan harus memberi pengembang antarmuka untuk mengontrol perutean dan penyeimbangan muatan. Berkat ini, pengembang akan dapat, menggunakan pola layanan mikro (agregator, proksi, rantai, cabang, dll), untuk menyelesaikan kedua tugas standar dan jarang muncul.
Dari perspektif bisnis, skalabilitas adalah salah satu alat manajemen risiko. Hal utama adalah untuk memenuhi permintaan pelanggan dengan menggunakan peralatan secara optimal:
- Dengan peningkatan kapasitas peralatan sebagai hasil dari kemajuan. Itu tidak akan menganggur karena ketidaksempurnaan perangkat lunak. Erlang berskala sempurna secara vertikal dan selalu dapat mendaur ulang semua inti CPU dan memori yang tersedia;
- Dalam lingkungan berawan, kami dapat mengontrol jumlah peralatan tergantung pada beban saat ini atau yang diperkirakan dan menjamin SLA.
Toleransi kesalahan
Pertimbangkan dua aksioma: "Kegagalan tidak bisa diterima" dan "Kegagalan akan selalu terjadi." Untuk bisnis, kegagalan perangkat lunak adalah kehilangan uang, dan lebih buruk lagi, reputasi. Menyeimbangkan antara potensi kerugian dan biaya pengembangan perangkat lunak yang tahan terhadap kesalahan, Anda seringkali dapat menemukan kompromi.
Dalam jangka pendek, arsitektur dengan toleransi kesalahan menghemat uang untuk pembelian solusi pengelompokan turnkey. Mereka mahal, dan mereka juga memiliki kesalahan.
Dalam jangka panjang, arsitektur yang toleran terhadap kesalahan berulang kali membayar biaya penerapannya pada semua tahap pengembangan.
Perpesanan di dalam basis kode pada tahap desain memungkinkan Anda untuk mengetahui secara terperinci interaksi komponen dalam sistem. Ini menyederhanakan tugas untuk merespons dan mengelola kegagalan, karena semua komponen penting menangani kegagalan, dan sistem yang dihasilkan tahu bagaimana secara otomatis kembali normal setelah kegagalan oleh desain.
Responsif
Terlepas dari kegagalan, aplikasi harus menanggapi permintaan dan memenuhi SLA. Kenyataannya adalah orang tidak mau menunggu, sehingga bisnis harus menyesuaikan. Lebih banyak aplikasi diharapkan menjadi sangat responsif.
Aplikasi responsif bekerja dalam mode waktu nyata. Erlang VM beroperasi dalam mode soft real-time. Untuk beberapa bidang, seperti perdagangan pertukaran, obat-obatan, manajemen peralatan industri, mode waktu-nyata yang keras adalah penting.
Sistem responsif meningkatkan UX dan membantu bisnis.
Hasil awal
Dalam merencanakan artikel ini, saya ingin berbagi pengalaman membuat broker pesan dan membangun sistem yang kompleks. Tetapi bagian teoretis dan motivasi ternyata cukup luas.
Pada bagian kedua artikel ini saya akan berbicara tentang nuansa implementasi dari titik pertukaran, templat pengiriman pesan dan aplikasinya.
Pada bagian ketiga, kami mempertimbangkan masalah umum organisasi layanan, perutean, dan penyeimbangan. Mari kita bicara tentang sisi praktis skalabilitas dan toleransi kesalahan sistem.
Akhir dari bagian pertama.
Foto @lucabravo .