Tujuannya adalah untuk membuat startup baru yang sarat muatan dalam kondisi modern. Kami akan mempertimbangkan pembuatan arsitektur menggunakan contoh
Billingolang , proyek penagihan universal untuk keperluan umum yang ditulis dalam golang. Proyek ini mencakup akses melalui API, situs web, integrasi ke dalam sistem akuntansi, laporan, dan grafik.
Sistem berulir tunggal pada awalnya terlempar kembali. Saya harus memilih antara Erlang, Golang dan Rust. Golang dipilih sebagai bahasa pemrograman utama, karena sulit untuk menemukan programmer Erlang, meskipun stabilitas dan hot-swapping kode adalah nilai tambah bagi Erlang. Karat, meskipun secara formal tidak memiliki kondisi balapan, masih lebih cocok bukan untuk menulis aplikasi, tetapi untuk driver dan sistem operasi.
Perpesanan antar komponen sistem tidak terjadi pada
RabbitMQ klasik, tetapi pada
NATS - yang terakhir menunjukkan tolok ukur pada server yang saat ini sedang digunakan, pesan 1M (+ 360K untuk pengelompokan) per detik versus 40K untuk kelinci. Ya, dan cluster lebih cepat dan lebih mudah daripada RabbitMQ.
Database:
MySQL InnoDB Cluster 7.6 (MySQL server 8.0). Tata letak yang cantik dan alat komunitas debugging
MySQL Workbench .
API - ditulis dalam bahasa
Swagger (OpenAPI 2.0). Ini menghindari kesalahan oleh programmer yang berbeda, menghasilkan kode yang bersih, didokumentasikan dengan baik dan dokumentasi API. Sayangnya, Swagger menggunakan
gorilla / mux untuk rooting secara default , tetapi setelah menghasilkan seluruh API, root akan diulang untuk
kataras / muxie - lebih cepat.
Frontend: dari framework yang tersedia: Iris, Beego dan Revel - Revel dipilih. Lebih lambat dari Iris, tetapi semuanya di luar kotak, termasuk integrasi dengan grafik. Beban utama masih akan ditanggung oleh API.
Penskalaan: semua komponen sistem dirakit dalam wadah LXC, sementara di depannya adalah penyeimbang
HAProxy . Gagasan skala turun ke secara konsisten beralih ke server yang lebih kuat dengan pelestarian struktur kontainer sebagai klien tumbuh, dan kemudian mendistribusikan kontainer ke server terpisah, menggantikan HAProxy dengan NATS. Selain penskalaan klasik dengan perangkat keras, selalu ada kemungkinan untuk meningkatkan jumlah goroutine di dalam penangan-wadah untuk meminta API dan situs. Meskipun proses ini, seperti yang telah ditunjukkan oleh praktik, memiliki keterbatasan logis.
Secara umum, ide utama artikel dan keyakinan saya yang mendalam adalah bahwa arsitektur awal proyek-proyek beban tinggi, dalam kondisi modern, tidak ada gunanya untuk dibangun di atas sistem single-threaded, terlepas dari infrastruktur yang dikembangkan bertahun-tahun dan kehadiran sejumlah besar programmer yang tersedia. Dan seluruh skema proyek harus dibuat pada awalnya dengan meletakkan transfer mudah ke peralatan yang lebih kuat dan didistribusikan. Ini akan memungkinkan di masa depan untuk dengan mudah menemukan keseimbangan antara penskalaan perangkat keras dan kode, tanpa mengalikan biaya.
Kesalahan umum dan paling umum yang dilakukan oleh startup baru adalah pengembangan awal yang buruk dari arsitektur. Menurut prinsip - "cepat mulai menulis, dan kemudian kita akan mengetahuinya." Sebagai aturan, sebagai akibatnya - ini mengarah pada keruntuhan proyek.
Seperti yang mereka katakan - "90% kesuksesan adalah persiapan". Jangan takut untuk menghabiskan awalnya untuk menciptakan arsitektur yang kompeten, bijaksana - itu akan membayar mahal.
Semoga beruntung