Përshëndetje, Habr. Aktualisht në OTUS është hapur regjistrimi për një grup të ri të kursit . Para fillimit të kursit dua të ndaj me ju artikullin tim autor.
Hyrje
Zgjedhja e stilit arkitektonik është një nga vendimmarrjet teknike më themelore në ndërtimin e një sistemi informatik. Në këtë seri artikujsh, propozoj të shqyrtojmë stilet më të njohura arkitektonike për ndërtimin e aplikacioneve dhe të përgjigjemi në pyetjen se kur cili stil arkitektonik është më i preferuar. Gjatë paraqitjes, do të përpiqem të ndihmoj një zinxhir logjik që shpjegon zhvillimin e stilëve arkitektonikë nga monolitët në mikroshërbime.
Pak histori
Nëse provoni të bëni një pyetje zhvilluesve: "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 në histori për të kuptuar se çfarë qëllimi kishin mikroshërbimet për krijimin e tyre.
Nëse flasim shkurtimisht, mikroshërbimet në kuptimin tonë aktual u krijuan kështu: në vitin 2011, James Lewis, duke analizuar punën e kompanive të ndryshme, vuri re shfaqjen e një modeli të ri "micro-app", i cili optimizoi SOA nga pikëpamja e shpejtësisë së shpërndarjes së shërbimeve. Disa më vonë, në vitin 2012, në samitin arkitektonik, modeli u riemërua në mikroshërbim. Kështu, qëllimi fillestar i përdorimit të mikroshërbimeve ishte përmirësimi i famshëm time to market.
Në "valën e hype-it" mikroshërbimet ishin në vitin 2015. Sipas disa studimeve, asnjë konferencë nuk kalonte pa një raport mbi mikroshërbimet. Më shumë se kaq, disa konferenca ishin dedikuar ekskluzivisht mikroshërbimeve. Tani shumë projekte fillojnë me përdorimin e këtij stili arkitektonik, dhe nëse projekti përfshin tonelata kodit legacy, me siguri po realizohet aktivisht migrimi në mikroshërbime.
Pavarësisht të gjitha të dhënave të mësipërme, numri i zhvilluesve që mund të përcaktojnë konceptin e "mikroshërbim" është ende mjaft i vogël. Por për këtë do të flasim pak më vonë…
Monolit
Stili arkitektonik që kundërshtohet me mikroshërbimin është monoliti (ose "të gjitha në një"). Nuk ka kuptim të flasim për monolitin, prandaj do të rendis menjëherë disavantazhet e këtij stili arkitektonik, të cilat nxisin zhvillimin e mëtejshëm të stileve arkitektonike: përmasat, lidhshmëria, shpërndarja, shkallëzueshmëria, qëndrueshmëria dhe ngurtësia. Më poshtë ju propozoj të njihemi me çdo njëri nga disavantazhet veç e veç.
Madhësia
Monolit është shumë i madh. Ai komunikon zakonisht me një bazë të dhënash shumë të madhe. Aplikimi bëhet tepër i madh për t'u kuptuar nga një zhvillues i vetëm në parim. Vetëm ata që kanë kaluar shumë kohë me këtë kod mund ta punojnë mirë me monolitin, ndërsa fillestarët do të kalojnë shumë kohë duke u munduar të kuptojnë monolitin dhe nuk është e sigurt që do të arrijnë ta kuptojnë. Zakonisht, gjatë punës me monolitin ka gjithmonë një “senior” të caktuar, i cili e njeh monolitin më shumë ose më pak mirë dhe ndihmon zhvilluesit e rinj për një vit deri në një vit e gjysmë. Natyrisht, ky senior është një pikë e vetme dështimi, dhe largimi i tij mund të çojë në vdekjen e monolitit.
Përgjegjshmëria
Monoliti është një ‘top i madh dhe i pista’ (big ball of mud), dhe ndryshimet në të mund të çojnë në pasoja të paparashikueshme. Duke bërë ndryshime në një vend, mund të dëmtoni monolitin në një tjetër (e njëjta gjë si ‘kemi bërë një gisht, dhe *@ ra’). Kjo lidhet me faktin se komponentët në monolit kanë lidhje shumë komplekse dhe, më e rëndësishmja, jo të qarta.
Zhvillimi
Zhvillimi i monolitit, për shkak të lidhjeve të komplikuara midis komponentëve të tij, është një proces i gjatë me një ritual të vetin. Ky ritual zakonisht nuk është plotësisht i standardizuar dhe transmetohet 'nga goja në gojë'.
Shkallëzueshmëria
Modulet e monolitit mund të kenë kërkesa konfliktuoze për burime, për këtë arsye është e nevojshme të kërkohet një kompromis në aspektin e harduerit. Imagjinoni se monoliti juaj përbëhet nga shërbimet A dhe B. Shërbimi A ka nevojë për një hard disk të madh, ndërsa shërbimi B kërkon memorie. Në këtë rast, ose mašina ku vendoset monoliti duhet të përmbushë kërkesat e të dy shërbimeve, ose do të duhet të çaktivizoni dorazi një nga shërbimet.
Një shembull tjetër (më klasik): shërbimi A është shumë më i popullarizuar sesa shërbimi B, kështu që dëshironi që të keni 100 shërbime A dhe 10 shërbime B. Përsëri, ka dy alternativa: ose zhvilloni 100 monolite të plota, ose në disa prej tyre do të duhet të çaktivizoni dorazi shërbimet B.
Besueshmëria
Pasi të gjitha shërbimet janë së bashku, nëse monoliti dështojnë, të gjitha shërbimet do të bien njëkohësisht. 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ë, por nga ana tjetër, për shkak të një gabimi në funksionalitetin që e përdor 0.001% e përdoruesve, mund të humbni të gjithë përdoruesit e sistemit tuaj.
Kritikë
Për shkak të madhësisë së monolitit, është e vështirë të kalosh në teknologji të reja. Si rezultat, një detyrë e veçantë shfaqet në ruajtjen e atij senior-it të ashtuquajtur. Stoku i teknologjisë i zgjedhur në fillim të projektit mund të bëhet një bllokadë që pengon zhvillimin e produktit.
Përfundim
Herën tjetër do të flasim për mënyrat se si njerëzit u përpoqën të zgjidhnin këto probleme duke kaluar në komponente dhe SOA.
Lexoni më shumë:
Burimi: habr.com
