Përshëndetje, Habr. Sot po vazhdoj serinë e publikimeve që kam shkruar posaçërisht për fillimin e një grupi të ri të kursit .
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.
Në ne kemi kuptuar monolitin dhe kemi arritur në përfundimin se monoliti ka një seri problemesh: madhësia, lidhshmëria, shpërndarja, shkallëzueshmëria, besueshmëria dhe rigiditeti.
Këtë herë propozoj të flas për mundësitë e organizimit të sistemit në formën e një grumbulli modulash/bibliotekash (arkitektura e orientuar ndaj komponenteve) ose shërbesh (arkitektura e orientuar ndaj shërbimeve).
Arkitektura e orientuar ndaj komponenteve
Arkitektura e orientuar nga komponentët parashikon që sistemi të funksionojë 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 për ripërdorim, zëvendësueshmëria, pavarësia nga konteksti, zgjerueshmëria, encapsulimi dhe pavarësia.
Me përdorim të duhur të komponentëve, zgjidhet problemi i "grumbullit të madh të papastërtive" (madhësia e madhe + lidhshmëria e lartë), dhe vetë komponentët mund të përfaqësojnë si njësitë e grumbullimit (modulet, bibliotekat), ashtu edhe njësitë e shpërndarjes (shërbimet). Njësitë e shpërndarjes nuk shihen gjithmonë në procesin e ekzekutimit: për shembull, aplikacioni web dhe baza e të dhënave shpërndahen së bashku.
Më së shpeshti, monolitët zhvillohen si një grup modulash. Ky qasje çon në sigurimin e pavarësisë së zhvillimit, por në të njëjtën kohë problemi i pavarësisë së shkallëzimit dhe shpërndarjes, disponueshmërisë dhe pavarësisë nga staku i përgjithshëm teknologjik mbetet. Pikërisht për këtë arsye, moduli është një komponentë gjysmë e pavarur.
Problemi kryesor i një monoliti të tillë është se ndarja në module është thjesht logjike dhe mund të prishët lehtësisht nga zhvilluesit. Mund të shfaqet një modul kryesor, i cili gradualisht më pas shndërrohet në një kaos, 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 kujdesin e një "arkitekti", i cili merret me kontrollin e kodit me kohë të plotë dhe i ndalon zhvilluesit që shkelin strukturën logjike.
"Monoliti 'ideal' përbëhet nga një grup moduli që janë ndarë logjikisht, çdo njëri prej të cilëve ka bazën e tij të dhënash.
Arkitekturë e orientuar në shërbim
Nëse me të vërtetë parashikohet organizimi i sistemit si një grup shërbimesh, atëherë flasim për arkitekturën e orientuar në shërbim. Parimet e saj janë: ndërveprueshmëria e aplikacioneve të orientuara në përdorues, përdorimi i shumëfishtë i shërbimeve të biznesit, pavarësia nga grupi i teknologjive dhe autonomi (evolucioni, shkallëzimi dhe implementimi të pavarura).
Arkitektura e orientuar nga shërbimet (SOA = service oriented architecture) zgjidh të gjitha problemet e shënuara të monolit: kur ndodhin ndryshime, preket vetëm një shërbim, dhe një API i qartë e mbështet inkapsulimin e mirë të komponentëve.
Por, jo gjithçka është kaq e lehtë: SOA sjell në pah probleme të reja. Thirrjet e largëta janë më të shtrenjta se ato lokale, dhe ri-shpërndarja e detyrave midis komponentëve është bërë dukshëm më e kushtueshme.
Në fakt, mundësia e shpërndarjes së pavarur është një karakteristikë shumë e rëndësishme e shërbimit. Nëse shërbimet duhet të shpërndahen së bashku ose, më shumë, në një rend të caktuar, atëherë sistemi nuk mund të konsiderohet i orientuar nga shërbimet. Në këtë rast flitet për një monolit të shpërndarë (i konsideruar si një anti- model jo vetëm nga pikëpamja e SOA, por edhe e arkitekturës së mikroshërbimeve).
Arkitektura e orientuar nga shërbimi mbështetet mirë nga komuniteti arkitektonik dhe ofruesit. Kjo do të thotë se ka shumë kurse dhe certifikata, si dhe modele të mira. Një nga ato është, për shembull, e njohura autobus shërbimi ndërmarrës (ESB = enterprise service bus). Megjithatë, ESB është një ngarkesë nga ofruesit, dhe nuk është domosdoshmërisht e nevojshme për t'u përdorur në SOA.
Piku i popullaritetit të arkitekturës së orientuar nga shërbimi ishte rreth vitit 2008, pas së cilës ajo filloi të bjerë, një rënie që u bë më e shpejtë pas shfaqjes së mikroshërbimeve (~2015).
Përfundimi
Pas diskutimit për mundësitë e organizimit të sistemeve të informacionit si shërbime dhe module, propozoj që të kalojmë te parimet e arkitekturës së mikroshërbimeve dhe t'i kushtojmë vëmendje të veçantë dallimeve midis arkitekturës së mikroshërbimeve dhe asaj të orientuar nga shërbimi në pjesën në vazhdim.
Burimi: habr.com
