Hello, habr. Pendaftaran untuk aliran kursus baharu dibuka sekarang di OTUS . Pada malam permulaan kursus, saya ingin berkongsi dengan anda artikel asal saya.
Pengenalan
Pilihan gaya seni bina adalah salah satu keputusan teknikal asas apabila membina sistem maklumat. Dalam siri artikel ini, saya mencadangkan untuk menganalisis gaya seni bina yang paling popular untuk aplikasi bangunan dan menjawab persoalan bilakah gaya seni bina yang paling disukai. Dalam proses pembentangan, saya akan cuba melukis rantaian logik yang menerangkan perkembangan gaya seni bina daripada monolit kepada perkhidmatan mikro.
Sedikit sejarah
Jika anda cuba bertanya kepada pembangun: "Mengapa kami memerlukan perkhidmatan mikro?", anda akan mendapat pelbagai jawapan. Anda akan mendengar bahawa perkhidmatan mikro meningkatkan kebolehskalaan, menjadikan kod lebih mudah difahami, meningkatkan toleransi kesalahan dan kadangkala anda akan mendengar bahawa ia membenarkan anda "membersihkan kod anda." Mari kita lihat sejarah untuk memahami tujuan di sebalik kemunculan perkhidmatan mikro.
Ringkasnya, perkhidmatan mikro dalam pemahaman semasa kami timbul seperti berikut: pada tahun 2011, James Lewis, menganalisis kerja pelbagai syarikat, menarik perhatian kepada kemunculan corak "apl mikro" baharu, yang mengoptimumkan SOA dari segi mempercepatkan penggunaan perkhidmatan. Tidak lama kemudian, pada tahun 2012, pada sidang kemuncak seni bina, corak itu dinamakan semula perkhidmatan mikro. Oleh itu, matlamat awal memperkenalkan perkhidmatan mikro adalah untuk menambah baik yang terkenal masa untuk memasarkan.
Perkhidmatan mikro berada dalam gelombang gembar-gembur pada tahun 2015. Menurut beberapa kajian, tidak ada satu persidangan pun yang lengkap tanpa laporan mengenai topik perkhidmatan mikro. Selain itu, beberapa persidangan didedikasikan secara eksklusif untuk perkhidmatan mikro. Pada masa kini, banyak projek mula menggunakan gaya seni bina ini, dan jika projek itu mengandungi banyak kod warisan, maka pemindahan ke perkhidmatan mikro mungkin sedang giat dijalankan.
Walaupun semua perkara di atas, sebilangan kecil pembangun masih boleh menentukan konsep "perkhidmatan mikro". Tetapi kita akan bercakap tentang ini sedikit kemudian...
Monolith
Gaya seni bina yang membezakan perkhidmatan mikro ialah monolit (atau semua-dalam-satu). Mungkin tidak masuk akal untuk memberitahu apa itu monolit, jadi saya akan segera menyenaraikan keburukan gaya seni bina ini, yang memulakan pembangunan lanjut gaya seni bina: saiz, ketersambungan, penggunaan, skalabiliti, kebolehpercayaan dan ketegaran. Di bawah ini saya mencadangkan untuk melihat setiap kekurangan secara berasingan.
saiz
Monolitnya sangat besar. Dan ia biasanya berkomunikasi dengan pangkalan data yang sangat besar. Aplikasi menjadi terlalu besar untuk difahami oleh seorang pembangun sama sekali. Hanya mereka yang telah menghabiskan banyak masa bekerja pada kod ini boleh bekerja dengan baik dengan monolit, manakala pemula akan menghabiskan banyak masa cuba memikirkan monolit dan tidak ada jaminan bahawa mereka akan memikirkannya. Biasanya, apabila bekerja dengan monolit, selalu ada orang kanan "bersyarat" yang mengetahui monolit dengan lebih kurang baik dan mengalahkan tangan pemaju baharu yang lain dalam masa satu setengah tahun. Sememangnya, senior bersyarat seperti itu adalah satu titik kegagalan, dan pemergiannya boleh menyebabkan kematian monolit.
Keterkaitan
Monolit ialah "bola lumpur besar", perubahan yang boleh membawa kepada akibat yang tidak dapat diramalkan. Dengan membuat perubahan di satu tempat, anda boleh merosakkan monolit di tempat lain (yang sama "anda menggaru telinga anda, *@ jatuh"). Ini disebabkan oleh fakta bahawa komponen dalam monolit mempunyai hubungan yang sangat kompleks dan, yang paling penting, tidak jelas.
Penyebaran
Menggunakan monolit, kerana hubungan yang kompleks antara komponennya, adalah proses yang panjang dengan ritualnya sendiri. Ritual sedemikian biasanya tidak diseragamkan sepenuhnya dan diteruskan "secara lisan."
Kebolehskalaan
Modul monolit mungkin mempunyai keperluan sumber yang bercanggah, memerlukan kompromi dibuat dari perspektif perkakasan. Bayangkan anda mempunyai monolit yang terdiri daripada perkhidmatan A dan B. Perkhidmatan A menuntut saiz cakera keras, dan perkhidmatan B menuntut RAM. Dalam kes ini, sama ada mesin di mana monolit dipasang mesti menyokong keperluan kedua-dua perkhidmatan, atau anda perlu melumpuhkan salah satu perkhidmatan secara manual.
Contoh lain (lebih klasik): perkhidmatan A jauh lebih popular daripada perkhidmatan B, jadi anda mahu ada 100 perkhidmatan A dan 10 perkhidmatan B. Sekali lagi, dua pilihan: sama ada kami menggunakan 100 monolit sepenuhnya atau pada beberapa kemudian perkhidmatan B perlu dilumpuhkan secara manual.
Kebolehpercayaan
Oleh kerana semua perkhidmatan terletak bersama, jika monolit jatuh, maka semua perkhidmatan jatuh sekaligus. Sebenarnya, ini mungkin tidak begitu teruk, sekurang-kurangnya tidak akan ada kegagalan separa dalam sistem yang diedarkan, tetapi sebaliknya, disebabkan oleh pepijat dalam fungsi yang digunakan oleh 0.001% pengguna, anda boleh kehilangan semua pengguna. sistem anda.
Inersia
Oleh kerana saiz monolit, sukar untuk beralih kepada teknologi baharu. Akibatnya, mengekalkan senior yang sama adalah tugas yang berasingan. Timbunan teknologi yang dipilih pada permulaan projek boleh menjadi blok yang menghalang pembangunan produk.
Kesimpulan
Lain kali kita akan bercakap tentang cara orang ramai cuba menyelesaikan masalah ini dengan beralih kepada komponen dan SOA.
Baca lebih lanjut:
Sumber: www.habr.com