Përshëndetje, Habr. Tani është hapur regjistrimi për një grup të ri kursi në OTUS. . Në prag të fillimit të kursit, dua të ndaj me ju artikullin tim të autorit.
Hyrje
Zgjedhja e stilit arkitektonik është një nga vendimet thelbësore teknike kur zhvillohet një sistem informacioni. Në këtë seri artikujsh, propozoj të shqyrtoj stilët më të njohur arkitektonikë për ndërtimin e aplikacioneve dhe të përgjigjem në pyetjen se kur cili stil arkitektonik është më i preferuar. Gjatë trajtimit, do të përpiqem të përçoj një lidhje logjike që shpjegon zhvillimin e stilëve arkitektonikë nga monolitët tek mikro-shërbimet.
Pak histori
Nëse përpiqeni të pyesni zhvilluesit: "Pse janë të nevojshme mikroshërbimet?", do të merrni përgjigje të ndryshme. Do të dëgjoni se mikroshërbimet përmirësojnë shkallëzimin, lehtësojnë kuptimin e kodit, përmirësojnë qëndrueshmërinë, ndonjëherë mund të dëgjoni se ato lejojnë "pastrimin e kodit". Le të kthehemi pas në histori, për të kuptuar se cila ishte qëllimi i krijimit të mikroshërbimeve.
Për ta thënë shkurt, mikroshërbimet sipas kuptimit tonë aktual u shfaqën si më poshtë: në vitin 2011, James Lewis, duke analizuar punën e ndryshme të kompanive, vuri re shfaqjen e një modeli të ri "micro-app", i cili optimizonte SOA nga pikëpamja e shpejtësisë së shpërndarjes së shërbimeve. Një kohë më vonë, në vitin 2012, në një samit arkitektonik, modeli u rinomua mikroshërbim. Kështu, qëllimi fillestar i zbatuar mikroshërbimeve ishte përmirësimi i të ashtuquajturit time to market.
Mikroshërbimet ishin në "valën e hype-it" në vitin 2015. Sipas disa hulumtimeve, asnjë konferencë nuk kalonte pa një prezantim mbi mikroshërbimet. Për më tepër, disa konferenca ishin të dedikuara për mikroshërbimet. Tani, shumë projekte fillojnë me përdorimin e këtij stili arkitektonik, dhe nëse një projekt përmban shumë kod të vjetër, pa dyshim që migrimi në mikroshërbime po realizohet aktivisht.
Megjithatë, pavarësisht të gjitha këtyre, ende ka një numër të vogël zhvilluesish që mund të përcaktojnë konceptin e "mikroshërbimit". Por për këtë do të flasim më vonë...
Monolit
Stili arkitektonik që është në opozitë me mikroshërbimin është monolit (ose "të gjitha në një"). Nuk ka shumë kuptim të flasësh për monolit, prandaj do të përmend menjëherë disavantazhet e këtij stili arkitektonik që nxitën zhvillimin e mëtejshëm të stileve arkitektonike: madhësia, lidhshmëria, shpërndarja, shkallëzimi, qëndrueshmëria dhe ngurtësia. Më poshtë do të paraqes çdo disavantazh në veçanti.
Madhësia
Monoliti është shumë i madh. Ai zakonisht komunikon me një bazë të dhënash shumë të madhe. Aplikacioni bëhet shumë i madh për ta kuptuar nga një zhvillues i vetëm në parim. Vetëm ata që kanë kaluar mjaft kohë me këtë kod mund të punojnë mirë me monolitin, ndërsa fillestarët do të shpenzojnë shumë kohë duke u përpjekur të kuptojnë monolitin dhe nuk është e sigurt që do të arrijnë ta bëjnë këtë. Zakonisht, kur pune me monolitin, ka gjithmonë një "senior" të kushteve, i cili e njeh monolitin më shumë ose më pak mirë dhe i ndihmon zhvilluesit e rinj për një vit ose më shumë. Sigurisht që ky senior është një pikë e vetme dështimi, dhe largimi i tij mund të çojë në shkatërrimin e monolitit.
Lidhshmëria
Monoliti paraqet një "gjurmë të madhe dhe të ndërlikuar" (big ball of mud), ndryshimet në të cilin mund të çojnë në pasoja të paparashikueshme. Duke bërë ndryshime në një vend, mund të dëmtohet monoliti në një tjetër (ajo që quhet "këmba e lajthitur, dhe doli në mënyrë të paparashikuar"). Kjo ndodh sepse komponentët në monolit kanë lidhshmëri shumë komplekse dhe, më e rëndësishmja, të paqarta.
Zhvillimi
Shpërndarja e monolitit për shkak të lidhjeve të komplikuara ndërmjet komponenteve të tij është një proces i gjatë dhe me ritet e veta. Ky ritual zakonisht nuk është përfundimisht i standardizuar dhe transmetohet "gojë më gojë".
Shkallëzueshmëria
Modulet e monolitit mund të kenë kërkesa të konfliktuara për burime, prandaj është e nevojshme të kërkohet një kompromis nga pikëpamja e harduerit. Imagjinoni se monoliti juaj është i përbërë nga shërbimet A dhe B. Shërbimi A ka nevoja të larta për hapësirë në disk, ndërsa shërbimi B ka nevoja për memorie të përkohshme. Në këtë rast, ose makina që ka monolitin duhet të mbështesë kërkesat e të dy shërbimeve, ose do të duhet të dezaktivoni ndonjë nga shërbimet manualisht.
Një shembull tjetër (më klasik): shërbimi A është shumë më i popullarizuar se shërbimi B, prandaj dëshironi që të keni 100 shërbime A dhe 10 shërbime B. Edhe një herë, ka dy mundësi: ose shpërndani 100 monolite të plotë, ose do të duhet të qëndroni manualisht disa nga shërbimet B.
Besueshmëria
Pasi të gjitha shërbimet janë së bashku, nëse monoliti bie, të gjitha shërbimet bien përnjëherësh. Në të vërtetë, ndoshta kjo nuk është aq e keqe, të paktën nuk do të ketë dështime të pjesshme në një sistem të shpërndarë, megjithatë, anasjelltas, për shkak të një gabimi në funksionalitetin që përdoret nga 0.001% e përdoruesve, mund të humbni të gjithë përdoruesit e sistemit tuaj.
Ngurtësia
Për shkak të madhësisë së monolitit, kalimi në teknologjitë e reja është i vështirë. Si pasojë, ruajtja e atij seniori të kushtëzuar bëhet një detyrë e veçantë. Teknologjia e zgjedhur në fillim të projektit mund të bëhet një bllokim që pengon zhvillimin e produktit.
Përfundimi
Herën tjetër do të flasim për mënyrat se si njerëzit përpoqen të zgjidhin këto probleme, duke kaluar në komponentë dhe SOA.
Lexoni më shumë:
Burimi: habr.com
