Ketika sebuah produk besar disusun atau sebuah perangkat lunak kecil mulai tumbuh menjadi leviathan, jalur pengembangan mana yang harus saya pilih? Haruskah saya menulis ulang semuanya dari awal atau melanjutkan tradisi "yang telah mapan"? Lagi pula, apakah ada baiknya merevisi konsep arsitektur?
Halo, orang Khabrovit! Nama saya Konstantin, dan saya adalah pengembang utama dari satu sistem yang cukup besar yang dimulai sekali sebagai percobaan. Sebuah situs PHP kecil yang dibuat secara harfiah "di lutut" dan, tentu saja, monolit. Seiring berjalannya waktu, situs tumbuh dan mengalami sejumlah masalah, solusi yang mengajukan pertanyaan "dan kemudian bagaimana?".
Monolith atau layanan mikro? Apa yang harus dipilih? Perbedaan mendasar antara pendekatan, menurut pendapat saya, adalah bahwa monolith menyiratkan siklus terpusat untuk memproses permintaan pengguna, dan layanan mikro - yang terdesentralisasi. Keuntungan dan kerugian umum dari kedua pendekatan ini telah banyak diketahui dan didaftar lebih dari satu kali (misalnya, di
sini , di
sini atau di
sini ). Namun, tidak ada faktor yang begitu jelas dan jelas yang mempengaruhi pilihan arsitektur.
- Memuat karyawan penuh waktu . Dengan perkembangan cepat produk, kumpulan tugas terakumulasi, yang tidak dapat diselesaikan dalam kerangka waktu yang dapat diterima - semua orang sibuk. Dan jika "penyumbatan" itu tunggal, tidak masuk akal untuk memperluas staf pengembang. Solusi yang jelas adalah kontraktor eksternal (perusahaan atau pekerja lepas). Tetapi bagaimana cara memberi mereka sepotong produk untuk bekerja tanpa risiko mengubahnya menjadi OpenSource, secara kasar? Dalam hal menggunakan layanan microservice, tugas ini jauh lebih mudah untuk diselesaikan.
- Sulitnya menyelam . Semakin besar produk, semakin banyak waktu yang diperlukan bagi karyawan baru untuk merasa nyaman di dalamnya. Terutama jika ada banyak standar berbeda dalam kode (ya, dokumentasi yang baik membuat prosesnya lebih mudah, tetapi jika tidak?) Dan kustomisasi untuk masing-masing kasus khusus. Dari sudut pandang ini, berurusan dengan bagian independen kecil jauh lebih mudah daripada dengan seluruh produk segera.
- Sumber daya pada beban puncak . Dalam praktik saya, ada kasus ketika beban di server kadang-kadang tumbuh menjadi nilai yang tidak dapat diterima (dan jika secara khusus - RAM habis, swap diaktifkan dan server berubah menjadi sayuran untuk sementara waktu), selama kerja bebas sepanjang waktu (memuat tidak lebih dari 30% dalam hal RAM) ) Dan puncak seperti itu terjadi secara tidak teratur dan dengan jeda yang lama. Dalam kasus monolith (kami percaya bahwa tidak ada tempat untuk mengoptimalkan kode), hanya koneksi server baru dengan salinan seluruh sistem untuk menghemat penyeimbangan beban. Dan dalam hal layanan microser, Anda dapat mengatur antrian pemrosesan (tentu saja, ini hanya berlaku untuk operasi kritis waktu yang cepat dan tidak diharapkan, seperti membongkar tabel Excel).
- Melakukan tugas di latar belakang . Cara mana faktor ini "mengguncang perahu" tergantung pada ukuran dan kompleksitasnya. Sebagai aturan, monolith dan timer (cron) sudah cukup. Tetapi jika tugas mulai menumpuk dalam kelompok besar, masalah juga muncul. Hal ini diperlukan untuk menyeimbangkan tugas cron. Layanan Microsoft sangat membantu situasi ini.
- Kompleksitas pelacakan . Dalam hal layanan mikro, persyaratan untuk pemeliharaan besi meningkat - di mana, apa dan bagaimana harus dikonfigurasikan. Monolith - secara kasar, beberapa pengaturan untuk semua node, layanan microser - pengaturan tergantung pada persyaratan layanan microser spesifik yang berjalan pada node.
- Persyaratan kualifikasi . Semakin banyak teknologi kebun binatang (dan biasanya tumbuh jika sistemnya adalah layanan mikro), semakin tinggi persyaratan untuk keterampilan dan pengetahuan karyawan biasa. Lagi pula, jika ada perbaikan atau masalah, mereka harus mengatasinya. Atau diperlukan lebih banyak profesional untuk menutupi seluruh tumpukan.
Apakah perlu memilih? Apakah game ini sepadan dengan lilin? Saya pikir pasti sepadan. Tetapi orang harus mendekati masalah dengan kepala dingin. Kalau tidak, beberapa masalah hanya akan digantikan oleh yang lain.
Dalam kasus saya, titik balik datang ketika situs berhenti untuk "masuk" ke sumber daya satu server. Kemudian diputuskan untuk menulis ulang sistem sesuai dengan opsi terbaik menurut saya - hibrida. Ada
rekomendasi umum untuk pengembangan produk dalam "kasus hybrid". Tetapi saya ingin menambahkannya dengan beberapa rekomendasi.
Saat merancang starter monolith, kemungkinan untuk koneksi lebih lanjut dari layanan eksternal harus diletakkan segera. Segera membangun komunikasi antar-komponen seolah-olah komponen ini sudah (atau hampir sudah) "layanan eksternal". Terutama jika mereka intensif sumber daya.
Segera pikirkan kebijakan untuk bekerja dengan cache dan penyimpanan data (database dan file). Misalnya, bagikan sesi pengguna.
Dan yang paling penting adalah jangan terburu-buru ke ekstrem. Bagi saya sendiri, saya menyimpulkan formula berikut untuk proyek yang bagus: "sistem yang efektif adalah sistem yang seimbang." Secara khusus, ini dinyatakan dalam fakta bahwa dalam layanan microser saya hanya mengambil fragmen besar yang terisolasi secara logis dari kernel. Dan kemudian, hanya jika setidaknya salah satu syarat terpenuhi:
- Pembatasan beban dan peramalan diperlukan, waktu tunda karena pelaksanaan tugas tidak penting pada gilirannya
- isolasi akan memberikan peningkatan produktivitas yang signifikan.
Sebagai hasil dari pendekatan ini, kami mendapatkan sistem, 95% dari fungsionalitas yang terletak di kernel, dan 5% di layanan microser. Tetapi pada saat yang sama, inti menyumbang hanya 60% dari total beban. Dan pada saat yang sama, Anda dapat menjamin bahwa beban pada masing-masing server tidak melebihi nilai kritis.
Jadi layanan microser (dari ukuran produk tertentu) bagus jika Anda menggunakannya hanya jika benar-benar diperlukan, dan bukan karena mode atau "karena itu keren." Ada
produk besar yang berhasil hidup sebagai monolit. Tapi terkadang monolit tidak bisa menyelesaikan masalah ...
Terima kasih