pengantar
Pemilihan gaya arsitektur merupakan salah satu solusi teknis mendasar dalam membangun sistem informasi. Dalam rangkaian artikel ini, saya mengusulkan untuk membongkar gaya arsitektur paling populer untuk aplikasi bangunan dan menjawab pertanyaan kapan gaya arsitektur yang paling disukai. Dalam prosesnya, saya akan mencoba menggambar rantai logis yang menjelaskan perkembangan gaya arsitektur dari monolit ke layanan mikro.
Sedikit sejarah
Jika Anda mencoba bertanya kepada developer: "Mengapa kita membutuhkan microservices?", Maka Anda akan mendapatkan berbagai jawaban. Anda akan mendengar bahwa layanan mikro meningkatkan penskalaan, membuat kode Anda lebih mudah dipahami, meningkatkan toleransi kesalahan, terkadang Anda akan mendengar bahwa layanan mikro memungkinkan Anda untuk "membersihkan kode". Mari kembali ke sejarah untuk memahami apa tujuan dari munculnya layanan mikro.
Singkatnya, layanan mikro dalam pemahaman kita saat ini muncul sebagai berikut: pada tahun 2011, James Lewis, menganalisis pekerjaan berbagai perusahaan, menarik perhatian pada munculnya pola baru "aplikasi mikro" yang mengoptimalkan SOA dalam hal mempercepat penyebaran layanan. Beberapa saat kemudian, pada tahun 2012, di arsitektur KTT, pola tersebut diubah namanya menjadi layanan mikro. Dengan demikian, tujuan awal memperkenalkan layanan mikro adalah untuk meningkatkan waktu yang terkenal ke pasar .
Layanan mikro berada di "gelombang hype" pada tahun 2015. Menurut beberapa penelitian, tidak ada konferensi yang lengkap tanpa pembicaraan tentang topik layanan mikro. Selain itu, beberapa konferensi didedikasikan secara eksklusif untuk layanan mikro. Saat ini, banyak proyek mulai menggunakan gaya arsitektur ini, dan jika proyek tersebut berisi banyak sekali kode warisan, kemungkinan besar migrasi ke layanan mikro dilakukan secara aktif.
Terlepas dari semua hal di atas, masih ada beberapa developer yang bisa mendefinisikan istilah "microservice". Tapi kita akan membicarakannya nanti ...
Monolit
Gaya arsitektur versus layanan mikro adalah monolit (atau all-in-one). Mungkin tidak masuk akal untuk mengatakan apa itu monolit, jadi saya akan segera membuat daftar kekurangan gaya arsitektur ini yang memulai pengembangan lebih lanjut gaya arsitektur: ukuran, koherensi, penerapan, skalabilitas, keandalan, dan kelembaman. Di bawah ini saya mengusulkan untuk mengetahui masing-masing kelemahan secara terpisah.
Ukuran
Monolitnya sangat besar. Dan dia biasanya berkomunikasi dengan database yang sangat besar. Aplikasi menjadi terlalu besar untuk dipahami oleh satu pengembang. Hanya mereka yang telah menghabiskan banyak waktu di belakang kode ini yang dapat bekerja dengan baik dengan monolit, sementara pemula akan menghabiskan banyak waktu untuk mencoba mencari tahu monolit dan bukan fakta bahwa mereka akan mengetahuinya. Biasanya, ketika bekerja dengan monolit, selalu ada senior “bersyarat” tertentu yang mengetahui monolit kurang lebih baik dan menampar pengembang baru lainnya selama satu atau setengah tahun. Secara alami, senior bersyarat seperti itu adalah satu titik kegagalan, dan kepergiannya dapat menyebabkan kematian monolit.
Keterhubungan
Sebuah monolit adalah "bola lumpur besar", perubahan yang dapat menyebabkan konsekuensi yang tidak terduga. Membuat perubahan di satu tempat, Anda dapat merusak monolit di tempat lain ("menggaruk telingaku, * @ jatuh"). Ini disebabkan oleh fakta bahwa komponen dalam monolit memiliki hubungan yang sangat kompleks dan, yang terpenting, tidak jelas.
Penyebaran
Menerapkan monolit, karena hubungan yang kompleks antara komponennya, merupakan proses yang panjang dengan ritualnya sendiri. Ritual ini biasanya tidak sepenuhnya dibakukan dan diteruskan "dari mulut ke mulut".
Skalabilitas
Modul monolith dapat memiliki persyaratan sumber daya yang bertentangan, yang memerlukan kompromi dalam hal perangkat keras. Bayangkan bahwa monolit Anda terdiri dari layanan A dan B. Layanan A menuntut ukuran hard disk, dan layanan B menuntut pada RAM. Dalam kasus ini, baik mesin tempat monolit diinstal harus mendukung persyaratan kedua layanan, atau Anda harus menonaktifkan salah satu layanan secara manual.
Contoh lain (lebih klasik): layanan A jauh lebih populer daripada layanan B, jadi Anda ingin layanan A menjadi 100, dan layanan B menjadi 10. Sekali lagi, dua opsi: kami menerapkan 100 monolit penuh, atau pada beberapa maka layanan B harus dinonaktifkan secara manual.
Keandalan
Karena semua layanan digabungkan, jika monolit jatuh, maka semua layanan jatuh sekaligus. Faktanya, mungkin ini tidak terlalu buruk, setidaknya tidak akan ada kegagalan parsial dalam sistem terdistribusi, tetapi di sisi lain, karena kesalahan dalam fungsionalitas yang digunakan 0,001% pengguna, Anda dapat kehilangan semua pengguna sistem Anda.
Kelembaman
Karena ukuran monolit, sulit untuk beralih ke teknologi baru. Akibatnya, retensi senior bersyarat itu adalah tugas terpisah. Tumpukan teknologi yang dipilih pada awal proyek dapat menjadi penghambat yang menghambat pengembangan produk.
Kesimpulan
Lain kali, kita akan berbicara tentang bagaimana orang mencoba memecahkan masalah ini dengan beralih ke komponen dan SOA.
Baca lebih banyak: