Halo, habr. Pendaftaran untuk jalur kursus baru dibuka sekarang di OTUS . Menjelang dimulainya kursus, saya ingin berbagi dengan Anda artikel asli saya.
pengenalan
Pemilihan gaya arsitektur merupakan salah satu keputusan teknis mendasar ketika membangun suatu sistem informasi. Dalam rangkaian artikel ini, saya mengusulkan untuk menganalisis gaya arsitektur paling populer untuk aplikasi bangunan dan menjawab pertanyaan kapan gaya arsitektur mana yang paling disukai. Dalam proses presentasinya, saya akan mencoba menggambar rantai logis yang menjelaskan perkembangan gaya arsitektur dari monolit hingga layanan mikro.
Sedikit sejarah
Jika Anda mencoba bertanya kepada pengembang: “Mengapa kita memerlukan layanan mikro?”, Anda akan mendapatkan beragam jawaban. Anda akan mendengar bahwa layanan mikro meningkatkan skalabilitas, membuat kode lebih mudah dipahami, meningkatkan toleransi kesalahan, dan terkadang Anda akan mendengar bahwa layanan tersebut memungkinkan Anda untuk "membersihkan kode Anda". Mari kita melihat sejarah untuk memahami tujuan di balik 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 “aplikasi mikro” baru, yang mengoptimalkan SOA dalam hal mempercepat penerapan layanan mikro. jasa. Beberapa saat kemudian, pada tahun 2012, pada pertemuan puncak arsitektur, pola tersebut berganti nama menjadi layanan mikro. Oleh karena itu, tujuan awal memperkenalkan layanan mikro adalah untuk memperbaiki layanan yang terkenal buruk waktu ke pasar.
Layanan mikro sedang populer pada tahun 2015. Menurut beberapa penelitian, tidak ada satu konferensi pun yang lengkap tanpa laporan tentang topik layanan mikro. Selain itu, beberapa konferensi didedikasikan khusus untuk layanan mikro. Saat ini, banyak proyek mulai menggunakan gaya arsitektur ini, dan jika proyek tersebut berisi banyak kode lama, maka migrasi ke layanan mikro mungkin sedang dilakukan secara aktif.
Terlepas dari semua hal di atas, sejumlah kecil pengembang masih dapat mendefinisikan konsep “layanan mikro”. Tapi kita akan membicarakannya nanti...
Monolith
Gaya arsitektur yang membedakan layanan mikro adalah monolit (atau all-in-one). Mungkin tidak masuk akal untuk mengatakan apa itu monolit, jadi saya akan segera membuat daftar kelemahan gaya arsitektur ini, yang menandai awal pengembangan gaya arsitektur lebih lanjut: ukuran, konektivitas, penerapan, skalabilitas, keandalan, dan kekakuan. Di bawah ini saya mengusulkan untuk melihat masing-masing kekurangannya secara terpisah.
Ukuran
Monolitnya sangat besar. Dan biasanya berkomunikasi dengan database yang sangat besar. Aplikasi menjadi terlalu besar untuk dipahami oleh satu pengembang. Hanya mereka yang telah menghabiskan banyak waktu mengerjakan kode ini yang dapat bekerja dengan baik dengan monolit, sementara pemula akan menghabiskan banyak waktu untuk mencoba memahami monolit dan tidak ada jaminan bahwa mereka akan memahaminya. Biasanya, ketika bekerja dengan monolit, selalu ada beberapa senior “bersyarat” yang mengetahui monolit kurang lebih baik dan mengalahkan pengembang baru lainnya dalam waktu satu setengah tahun. Tentu saja, senior bersyarat seperti itu adalah satu titik kegagalan, dan kepergiannya dapat menyebabkan kematian monolit.
keterhubungan
Monolit adalah “bola lumpur besar”, yang perubahannya dapat menimbulkan konsekuensi yang tidak terduga. Dengan melakukan perubahan di satu tempat, Anda dapat merusak monolit di tempat lain (“sama saja “Anda menggaruk telinga, *@ terjatuh”). Hal ini disebabkan oleh fakta bahwa komponen-komponen dalam monolit memiliki hubungan yang sangat kompleks dan, yang terpenting, hubungan yang tidak jelas.
Penyebaran
Pengerjaan sebuah monolit, karena rumitnya hubungan antar komponennya, memerlukan proses panjang dengan ritual tersendiri. Ritual seperti itu biasanya tidak sepenuhnya distandarisasi dan diwariskan “secara lisan”.
Skalabilitas
Modul Monolith mungkin memiliki kebutuhan sumber daya yang bertentangan, sehingga memerlukan kompromi dalam hal perangkat keras. Bayangkan Anda memiliki monolit yang terdiri dari layanan A dan B. Layanan A menuntut ukuran hard drive, dan layanan B menuntut RAM. Dalam hal ini, mesin tempat monolit dipasang harus mendukung persyaratan kedua layanan, atau Anda harus menonaktifkan salah satu layanan secara manual dan artifisial.
Contoh lain (lebih klasik): layanan A jauh lebih populer daripada layanan B, jadi Anda ingin ada 100 layanan A, dan 10 layanan B. Sekali lagi, ada dua opsi: kami menerapkan 100 monolit lengkap, atau pada beberapa kemudian layanan B harus dinonaktifkan secara manual.
Keandalan
Karena semua layanan terletak bersama, jika monolit jatuh, semua layanan akan jatuh sekaligus. Faktanya, ini mungkin tidak terlalu buruk, setidaknya tidak akan ada kegagalan sebagian dalam sistem terdistribusi, tetapi di sisi lain, karena bug dalam fungsionalitas yang digunakan oleh 0.001% pengguna, Anda dapat kehilangan semua pengguna. dari sistem Anda.
Kelembaman
Karena ukuran monolitnya, sulit untuk beralih ke teknologi baru. Akibatnya, mempertahankan senior yang sama adalah tugas tersendiri. Tumpukan teknologi yang dipilih pada awal proyek dapat menjadi hambatan yang menghambat pengembangan produk.
Kesimpulan
Lain kali kita akan membahas tentang bagaimana orang mencoba memecahkan masalah ini dengan beralih ke komponen dan SOA.
Baca selengkapnya:
Sumber: www.habr.com