Përshëndetje, Habr. Sot vazhdoj një seri botimesh që kam shkruar posaçërisht për fillimin e një rryme të re të kursit. .
Paraqitje
Zgjedhja e stilit arkitektonik është një nga vendimet themelore teknike gjatë ndërtimit të një sistemi informacioni. Në këtë seri artikujsh, unë propozoj të analizoj stilet më të njohura arkitekturore për aplikimet e ndërtimit dhe t'i përgjigjem pyetjes se kur stili arkitektonik është më i preferuari. Në procesin e prezantimit, do të përpiqem të vizatoj një zinxhir logjik që shpjegon zhvillimin e stileve arkitekturore nga monolitet në mikroshërbime.
В ne u morëm me monolitin dhe arritëm në përfundimin se monoliti ka një sërë problemesh: madhësinë, lidhjen, vendosjen, shkallëzueshmërinë, besueshmërinë dhe ngurtësinë.
Këtë herë propozoj të flasim për mundësitë e organizimit të një sistemi si një grup modulesh/bibliotekash (arkitekturë e orientuar nga komponentët) ose shërbime (arkitekturë e orientuar nga shërbimi).
Arkitektura e orientuar nga komponentët
Arkitektura e orientuar nga komponentët përfshin ekzekutimin e një sistemi si një grup përbërësish që mund të përdoren si në projektet aktuale ashtu edhe në të ardhmen. Kur ndahet një sistem në komponentë, merren parasysh sa vijon: ripërdorimi i tyre, zëvendësueshmëria e tyre, pavarësia e kontekstit, shtrirja, kapsulimi dhe pavarësia.
Me përdorimin e duhur të komponentëve, problemi i "topit të madh të papastërtisë" (madhësia e madhe + bashkim i lartë) zgjidhet, dhe vetë përbërësit mund të jenë si njësi montimi (module, biblioteka) dhe njësi vendosjeje (shërbime). Njësitë e vendosjes nuk përshtaten gjithmonë me procesin e ekzekutimit: për shembull, një aplikacion ueb dhe një bazë të dhënash vendosen së bashku.
Më shpesh, monolitët zhvillohen si një grup modulesh. Kjo qasje çon në zhvillim të pavarur, por problemet e shkallëzimit dhe vendosjes së pavarur, tolerancës së gabimeve dhe pavarësisë nga grupi i përgjithshëm i teknologjisë mbeten. Kjo është arsyeja pse moduli është një komponent pjesërisht i pavarur.
Problemi më i madh me një monolit të tillë është se ndarja në module është thjesht logjike dhe mund të shkelet lehtësisht nga zhvilluesit. Mund të shfaqet një modul bazë, i cili gradualisht kthehet në një vendgrumbullim mbeturinash, grafiku i varësive midis moduleve mund të rritet, etj. Për të shmangur probleme të tilla, zhvillimi duhet të kryhet ose nga një ekip shumë i pjekur, ose nën drejtimin e një "arkitekti" i cili është i angazhuar në rishikimin e kodit me kohë të plotë dhe rrah duart e zhvilluesve që shkelin strukturën logjike.
Monoliti "ideal" është një grup modulesh të ndara logjikisht, secila prej të cilave shikon në bazën e të dhënave të saj.
Arkitektura e orientuar drejt shërbimit
Nëse sistemi supozohet të organizohet në formën e një grupi shërbimesh, atëherë flasim për një arkitekturë të orientuar drejt shërbimit. Parimet e tij janë ndërveprueshmëria e aplikacionit të përqendruar te përdoruesi, ripërdorimi i shërbimit të biznesit, pavarësia e grumbullit të teknologjisë dhe autonomia (evolucioni i pavarur, shkallëzimi dhe vendosja).
Arkitektura e orientuar nga shërbimi (SOA = arkitekturë e orientuar nga shërbimi) zgjidh të gjitha problemet e identifikuara të një monoliti: vetëm një shërbim ndikohet kur ndodh një ndryshim dhe një API e përcaktuar mirë mbështet kapsulimin e mirë të komponentëve.
Por jo gjithçka është aq e qetë: SOA krijon probleme të reja. Thirrjet në distancë janë më të shtrenjta se ato lokale dhe rishpërndarja e përgjegjësive ndërmjet komponentëve është bërë dukshëm më e shtrenjtë.
Nga rruga, mundësia e vendosjes së pavarur është një veçori shumë e rëndësishme e shërbimit. Nëse shërbimet duhet të vendosen së bashku ose, për më tepër, në një sekuencë të caktuar, atëherë sistemi nuk mund të konsiderohet i orientuar drejt shërbimit. Në këtë rast, ata flasin për një monolit të shpërndarë (i konsideruar si një anti-model jo vetëm nga pikëpamja e SOA, por edhe nga pikëpamja e arkitekturës së mikroshërbimit).
Arkitektura e orientuar drejt shërbimit mbështetet mirë nga komuniteti arkitektonik dhe shitësit. Kjo nënkupton praninë e shumë kurseve dhe certifikatave, modele të zhvilluara mirë. Kjo e fundit përfshin, për shembull, autobusin e mirënjohur të shërbimit të ndërmarrjes (ESB = autobus i shërbimit të ndërmarrjes). Në të njëjtën kohë, ESB është një bagazh nga shitësit; nuk duhet domosdoshmërisht të përdoret në SOA.
Popullariteti i arkitekturës së orientuar nga shërbimi arriti kulmin rreth vitit 2008, pas së cilës filloi të bjerë, gjë që u bë dukshëm më dramatike pas ardhjes së mikroshërbimeve (~2015).
Përfundim
Pasi kemi diskutuar mundësitë e organizimit të sistemeve të informacionit në formën e shërbimeve dhe moduleve, unë propozoj që më në fund të kalojmë në parimet e arkitekturës së mikroshërbimeve dhe t'i kushtojmë vëmendje të veçantë ndryshimit midis arkitekturës së mikroservisit dhe arkitekturës së orientuar nga shërbimi në pjesën tjetër.
Burimi: www.habr.com