Përshëndetje, Habr. Sot po vazhdoj serinë e publikimeve që kam shkruar posaçërisht për fillimin e një fluksi të ri të kursit .
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.
Në ne e kuptuam monolitin dhe arritëm në përfundimin se monoliti ka disa probleme: madhësia, lidhshmëria, shpërndarja, shkallëzueshmëria, besueshmëria dhe ngurtësia.
Këtë herë propozoj të flasim për mundësitë e organizimit të sistemit si një grup modulash/librash (arkitekturë e orientuar nga komponentët) ose shërbesh (arkitekturë e orientuar nga shërbimet).
Arkitektura e orientuar nga komponentët
Arkitektura e orientuar nga komponentët parashikon realizimin e sistemit si një grup komponentësh, të cilët mund të përdoren si në projektet aktuale ashtu edhe në ato të ardhshme. Gjatë ndarjes së sistemit në komponentë, merren parasysh: përshtatshmëria e tyre për rishfytim, zëvendësueshmëria, pavarësia nga konteksti, zgjerueshmëria, inkapsulimi dhe pavarësia.
Me përdorimin e duhur të komponentëve, zgjidhet problemi i 'të madhit bllok i baltës' (madhësi e madhe + lidhshmëri e lartë), dhe vetë komponentët mund të përfaqësojnë si njësi të ndërtimit (modula, libra), ashtu edhe njësi shpërndarjeje (shërbime). Njësitë e shpërndarjes nuk shfaqen gjithmonë në procesin e ekzekutimit: për shembull, aplikacionet web dhe baza e të dhënave ndahen së bashku.
Më së shpeshti, monolitët zhvillohen si një grup modulash. Ky qasje çon në sigurimin e pavarësisë së zhvillimit, por problemet e shkallëzimit dhe shpërndarjes së pavarur, qëndrueshmërisë dhe pavarësisë nga staku teknologjik i përbashkët mbeten. Prandaj, moduli është një komponentë pjesërisht të pavarur.
Problemi kryesor i një monoliti të tillë është që ndarja në module është thjesht logjike dhe mund të prishët lehtësisht nga zhvilluesit. Mund të lindë një modul që quhet core, i cili gradualisht shndërrohet në një plehërishte, mund të rritet grafiku i varësive midis moduleve dhe kështu me radhë. Për të shmangur këto probleme, zhvillimi duhet të kryhet ose nga një ekip shumë të pjekur, ose nën drejtimin e një "arkitekti" i cili merret me rishikimin e kodit në mënyrë të plotë dhe ndëshkon zhvilluesit që shkelin strukturën logjike.
Monoliti "ideal" paraqet një grup moduleve të ndara logjikisht, secili prej të cilëve shikon në bazën e vet të të dhënave.
Arkitektura ndihmuese në shërbim
Nëse pranohet organizimi i sistemit si një grup shërbimesh, atëherë flasim për arkitekturën ndihmuese në shërbim. Parimet e saj: ndërveprueshmëria e aplikacioneve që janë të orientuara ndaj përdoruesve, përdorimi i shumëfishtë i shërbimeve të biznesit, pavarësia nga grupi i teknologjive dhe autonomi (evolucioni, shkallëzimi dhe përcaktimi i pavarur).
Arkitektura ndihmuese në shërbim (SOA = service oriented architecture) zgjidh të gjitha problemet e shënuara nga monoliti: kur duhet bërë një ndryshim, preket vetëm një shërbim, dhe një API i definuar qartë ruan një inkapsulim të mirë të komponenteve.
Por nuk është gjithçka kaq e lehtë: SOA çon në lindjen e problemeve të reja. Thirrjet e largëta janë më të shtrenjta se ato lokale, dhe ripërkufizimi i detyrave ndërmjet komponentëve është bërë ndjeshëm më i shtrenjtë.
Pas një kohe, mundësia e shpërndarjes së pavarur është një karakteristikë shumë e rëndësishme e shërbimeve. Nëse shërbimet duhet të shpërndahen së bashku ose, aq më shumë, në një rend të caktuar, atëherë sistemi nuk mund të konsiderohet si arkitekturë ndihmuese në shërbim. Në këtë rast, flasim për një monolit të shpërndarë (i cili konsiderohet një anti-model jo vetëm nga këndvështrimi i SOA-s, por edhe i arkitekturës mikro-shërbimesh).
Arkitektura ndihmuese në shërbim mbështetet mjaft mirë nga komuniteti arkitektonik dhe nga ofruesit. Kjo tregon ekzistencën e shumë kurseve dhe certifikimeve, dhe modele të mirëpunuara. Një nga këto është, për shembull, autobusi i shërbimeve të korporatave (ESB = enterprise service bus). Megjithatë, ESB është një bagazh nga ofruesit, dhe nuk është e nevojshme që të përdoret domosdoshmërisht në SOA.
Kulminacioni moment i arkitekturës orientuar nga shërbimet ishte rreth vitit 2008, pas së cilës ajo filloi të bjerë, një rënie që u bë shumë më e theksuar pas shfaqjes së mikroshërbimeve (~2015).
Përfundim
Pas diskutimit mbi mundësitë e organizimit të sistemeve informacioni në formë shërbimesh dhe modulash, unë propozoj që përfundimisht të kalojmë në parimet e arkitekturës së mikroshërbimeve dhe t'i kushtojmë vëmendje të veçantë dallimit midis arkitekturës së mikroshërbimeve dhe asaj orientuar nga shërbimet në pjesën e ardhshme.
Burimi: habr.com
