Halo, habr. Pendaftaran kanggo aliran kursus anyar saiki mbukak ing OTUS . Ing wayah wengi wiwitan kursus, aku pengin nuduhake karo sampeyan artikel asliku.
Pambuka
Pilihan gaya arsitektur minangka salah sawijining keputusan teknis dhasar nalika mbangun sistem informasi. Ing seri artikel iki, aku ngusulake kanggo nganalisa gaya arsitektur sing paling populer kanggo aplikasi bangunan lan mangsuli pitakon babagan kapan gaya arsitektur sing paling disenengi. Ing proses presentasi, aku bakal nyoba nggambar rantai logis sing nerangake pangembangan gaya arsitektur saka monoliths menyang microservices.
Sawetara sejarah
Yen sampeyan nyoba takon pangembang: "Napa kita butuh layanan mikro?", Sampeyan bakal entuk macem-macem jawaban. Sampeyan bakal krungu manawa microservices nambah skalabilitas, nggawe kode luwih gampang dimangerteni, nambah toleransi kesalahan, lan kadhangkala sampeyan bakal krungu yen ngidini sampeyan "ngresiki kode sampeyan." Ayo goleki sejarah kanggo ngerti tujuane muncule layanan mikro.
Ing cendhak, microservices ing pemahaman kita saiki muncul minangka nderek: ing 2011, James Lewis, nganalisa karya saka macem-macem perusahaan, narik kawigaten manungsa waé kanggo munculé pola "micro-app" anyar, kang optimized SOA ing syarat-syarat akselerasi penyebaran layanan. Luwih mengko, ing 2012, ing puncak arsitektur, pola kasebut diarani microservice. Mangkono, tujuan awal ngenalake layanan mikro yaiku kanggo nambah kondhang wektu kanggo pasar.
Microservices ana ing gelombang hype ing 2015. Miturut sawetara panaliten, ora ana konferensi siji sing rampung tanpa laporan babagan topik layanan mikro. Kajaba iku, sawetara konferensi khusus khusus kanggo layanan mikro. Saiki, akeh proyek sing wiwit nggunakake gaya arsitektur iki, lan yen proyek kasebut ngemot akeh kode warisan, mula migrasi menyang layanan mikro bisa uga ditindakake kanthi aktif.
Senadyan kabeh kasebut ing ndhuwur, sawetara pangembang sing cukup cilik isih bisa nemtokake konsep "layanan mikro". Nanging kita bakal ngomong babagan iki mengko ...
Monolith
Gaya arsitektur sing mbedakake layanan mikro yaiku monolit (utawa kabeh-ing-siji). Iku mbokmenawa ora nggawe pangertèn kanggo ngomong apa monolith, supaya aku bakal langsung dhaftar cacat gaya arsitektur iki, kang miwiti pangembangan luwih saka gaya arsitektur: ukuran, panyambungan, penyebaran, skalabilitas, linuwih lan rigidity. Ing ngisor iki aku ngusulake kanggo ndeleng saben kekurangan kanthi kapisah.
ukuran
Monolith gedhe banget. Lan biasane komunikasi karo database gedhe banget. Aplikasi dadi gedhe banget kanggo siji pangembang kanggo ngerti kabeh. Mung wong-wong sing wis ngginakaken akèh wektu kanggo nggarap kode iki bisa uga karo monolith ing, nalika pamula bakal nglampahi akeh wektu kanggo nyoba kanggo ngerti monolith lan ora njamin sing padha bakal ngerti. Biasane, nalika nggarap monolith, mesthi ana sawetara senior "kondisi" sing ngerti monolith luwih utawa kurang lan ngalahake tangan pangembang anyar liyane sajrone setahun setengah. Alamiah, senior saratipun punika titik siji saka Gagal, lan departure bisa mimpin kanggo pati saka monolith.
Keterkaitan
Monolith minangka "bal lendhut gedhe", owah-owahan sing bisa nyebabake akibat sing ora bisa ditebak. Kanthi owah-owahan ing sak panggonan, sampeyan bisa ngrusak monolit ing liyane (padha "sampeyan scratched kuping, * @ tiba mati"). Iki amarga kasunyatan sing komponen ing monolith wis banget Komplek lan, paling Jahwéh, sesambetan non-jelas.
Penyebaran
Nyebarake monolit, amarga hubungan sing rumit antarane komponen kasebut, minangka proses sing dawa karo ritual dhewe. Ritual kasebut biasane ora standar lan diwarisake kanthi "lisan".
Skalabilitas
Modul monolith bisa uga duwe kabutuhan sumber daya sing bertentangan, sing mbutuhake kompromi saka perspektif hardware. Mbayangno sing duwe monolith dumadi saka layanan A lan B. Service A nuntut ing ukuran hard drive, lan layanan B nuntut ing RAM. Ing kasus iki, salah siji mesin kang monolith diinstal kudu ndhukung syarat loro layanan, utawa sampeyan kudu kanthi manual, artificially mateni salah siji saka layanan.
Conto liyane (luwih klasik): layanan A luwih populer tinimbang layanan B, dadi sampeyan pengin ana 100 layanan A, lan 10 layanan B. Maneh, rong pilihan: salah siji kita masang 100 monoliths lengkap, utawa ing sawetara banjur layanan B kudu dipateni kanthi manual.
Linuwih
Amarga kabeh layanan dumunung bebarengan, yen monolit tiba, banjur kabeh layanan tiba bebarengan. Nyatane, iki bisa uga ora dadi ala, paling ora bakal ana kegagalan parsial ing sistem sing disebarake, nanging ing sisih liya, amarga bug ing fungsi sing digunakake dening 0.001% pangguna, sampeyan bisa ilang kabeh pangguna. saka sistem sampeyan.
Inersia
Amarga ukuran monolit, angel ngalih menyang teknologi anyar. Akibaté, njaga senior sing padha minangka tugas sing kapisah. Tumpukan teknologi sing dipilih ing wiwitan proyek bisa dadi blok sing ngalangi pangembangan produk.
kesimpulan
Sabanjure, kita bakal ngomong babagan carane wong nyoba ngatasi masalah kasebut kanthi pindhah menyang komponen lan SOA.
Waca liyane:
Source: www.habr.com