Në inxhinierinë e softuerëve, një arkitekturë mikroshërbimesh është një model arkitekturor që organizon një aplikacion në një koleksion shërbimesh të lidhura lirshëm dhe të detajuara që komunikojnë përmes protokolleve të lehta. Ky model u lejon ekipeve të zhvillojnë, vendosin dhe shkallëzojnë shërbimet në mënyrë të pavarur, duke përmirësuar modularitetin, shkallëzueshmërinë dhe përshtatshmërinë. Megjithatë, ai sjell kompleksitet shtesë, veçanërisht në menaxhimin e sistemeve të shpërndara dhe komunikimin ndër-shërbime, duke e bërë zbatimin fillestar më sfidues krahasuar me një arkitekturë monolitike.
Përkufizim
Nuk ka një përkufizim të vetëm, të pranuar universalisht, për mikroshërbimet. Megjithatë, ato karakterizohen përgjithësisht nga një fokus në modularitet, me secilin shërbim të projektuar rreth një aftësie specifike biznesi. Këto shërbime janë të lidhura lirshëm, të zbatueshme në mënyrë të pavarur dhe shpesh zhvillohen dhe shkallëzohen veçmas, duke mundësuar fleksibilitet dhe shkathtësi më të madhe në menaxhimin e sistemeve komplekse. Arkitektura e mikroshërbimeve është e lidhur ngushtë me parime të tilla si dizajni i drejtuar nga domeni, decentralizimi i të dhënave dhe qeverisja, dhe fleksibiliteti për të përdorur teknologji të ndryshme që shërbimet individuale të përmbushin më së miri kërkesat e tyre.
Përdorimi
Është e zakonshme që arkitekturat e mikroshërbimeve të përdoren për aplikacionet cloud-native, informatikën pa server dhe aplikacionet që përdorin vendosjen e kontejnerëve të lehtë nëpërmjet virtualizimit në nivel sistemi operativ. Sipas Fowler, për shkak të numrit të madh (në krahasim me implementimet monolitike të aplikacioneve) të shërbimeve, ofrimi i vazhdueshëm i decentralizuar dhe DevOps me monitorim holistik të shërbimit janë të nevojshme për të zhvilluar, mirëmbajtur dhe operuar në mënyrë efektive aplikacione të tilla. Një pasojë (dhe arsyetim për) ndjekjen e kësaj qasje është se mikroshërbimet individuale mund të shkallëzohen individualisht. Në qasjen monolitike, një aplikacion që mbështet tre funksione do të duhej të shkallëzohej në tërësinë e tij edhe nëse vetëm njëri prej këtyre funksioneve kishte një kufizim burimesh. Me mikroshërbimet, vetëm mikroshërbimi që mbështet funksionin me kufizime burimesh duhet të shkallëzohet, duke ofruar kështu përfitime të optimizimit të burimeve dhe kostos. Pavarësisht përfitimeve të saj, arkitektura e mikroshërbimeve paraqet sfida të tilla si rritja e kompleksitetit operacional, vonesa e rrjetit dhe nevoja për mekanizma të fuqishëm monitorimi dhe tolerance ndaj gabimeve.
Arkitektura e bazuar në qeliza në mikroshërbime
Arkitektura e bazuar në qeliza është një dizajn i informatikës së shpërndarë në të cilin burimet llogaritëse janë të organizuara në njësi të pavarura të quajtura qeliza. Çdo qelizë vepron në mënyrë të pavarur, duke trajtuar një nëngrup kërkesash duke ruajtur shkallëzueshmërinë, izolimin e defekteve dhe disponueshmërinë.
Një qelizë zakonisht përbëhet nga shumë mikroshërbime dhe funksionon si një njësi autonome. Në disa zbatime, grupe të tëra mikroshërbimesh replikohen nëpër qeliza të shumta, duke mundësuar që kërkesat të ridrejtohen në një qelizë tjetër operative nëse njëra prej tyre përjeton një dështim. Kjo qasje synon të përmirësojë qëndrueshmërinë në të gjithë sistemin duke kufizuar ndikimin e dështimeve të lokalizuara.
Disa implementime përfshijnë ndërprerës qarku brenda dhe midis qelizave. Brenda një qelize, ndërprerësit e qarkut mund të përdoren për të zbutur dështimet kaskaduese midis mikroshërbimeve, ndërsa ndërprerësit e qarkut ndërqelizor mund të izolojnë qelizat që dështojnë dhe të ridrejtojnë trafikun tek ato që mbeten funksionale.
Arkitektura e bazuar në qeliza është adoptuar në disa sisteme të shpërndara në shkallë të gjerë ku izolimi i defekteve dhe redundanca janë përparësi të projektimit. Zbatimi i saj ndryshon në bazë të kërkesave të sistemit, kufizimeve të infrastrukturës dhe qëllimeve specifike operacionale.
Histori
Në vitin 1999, zhvilluesi i softuerëve Peter Rodgers kishte punuar në projektin kërkimor Dexter në Hewlett Packard Labs, qëllimi i të cilit ishte ta bënte kodin më pak të brishtë dhe t'i bënte sistemet softuerike komplekse në shkallë të gjerë, të qëndrueshme ndaj ndryshimeve. Në fund të fundit, kjo rrugë kërkimore çoi në zhvillimin e informatikës së orientuar drejt burimeve (ROC), një abstraksion i përgjithësuar i llogaritjes në të cilin REST është një nëngrup i veçantë. Në vitin 2005, gjatë një prezantimi në konferencën Web Services Edge, Rodgers argumentoi për "shërbimet REST" dhe deklaroi se "Komponentët e softuerëve janë Mikro-Shërbimet-Web... Mikro-Shërbimet përbëhen duke përdorur tubacione të ngjashme me Unix (Uebi takon Unix = bashkim i vërtetë i lirshëm). Shërbimet mund të thërrasin shërbime (+ kohë ekzekutimi të shumëfishta gjuhësore). Asambletë komplekse të shërbimeve abstraktohen pas ndërfaqeve të thjeshta URI. Çdo shërbim, në çdo granularitet, mund të ekspozohet." Ai përshkroi se si një platformë mikroshërbimesh e projektuar mirë "zbaton parimet themelore arkitekturore të shërbimeve të Uebit dhe REST së bashku me planifikimin dhe tubacionet e ngjashme me Unix për të ofruar fleksibilitet radikal dhe thjeshtësi të përmirësuar në arkitekturat e orientuara drejt shërbimeve."
Gjithashtu në vitin 2005, Alistair Cockburn shkroi rreth arkitekturës hekzagonale, e cila është një model dizajni softuerësh që përdoret së bashku me mikroshërbimet. Ky model e bën të mundur dizajnin e mikroshërbimit, pasi izolon në shtresa logjikën e biznesit nga shërbimet ndihmëse të nevojshme për të vendosur dhe drejtuar mikroshërbimin plotësisht të pavarur nga të tjerët.
Granulariteti i mikroshërbimeve
Përcaktimi i nivelit të duhur të granularitetit (mikro) të shërbimit në një arkitekturë mikroshërbimesh shpesh kërkon bashkëpunim përsëritës midis arkitektëve dhe zhvilluesve. Ky proces përfshin vlerësimin e kërkesave të përdoruesit, përgjegjësive të shërbimit dhe karakteristikave arkitekturore, siç janë kërkesat jo-funksionale. Neal Ford thekson rolin e faktorëve integrues dhe disintegrues në këtë kontekst. Faktorët integrues, siç janë transaksionet e përbashkëta ose proceset e lidhura ngushtë, favorizojnë kombinimin e shërbimeve, ndërsa faktorët disintegrues, siç janë toleranca ndaj gabimeve ose shkallëzueshmëria e pavarur, inkurajojnë ndarjen e shërbimeve për të përmbushur qëllimet operacionale dhe arkitekturore. Përveç kësaj, funksionet e fitnesit, siç propozohen nga Neal Ford, mund të përdoren për të validuar vendimet arkitekturore dhe granularitetin e shërbimit duke matur vazhdimisht cilësitë ose sjelljet e sistemit që janë kritike për palët e interesuara, duke siguruar përputhshmëri me objektivat e përgjithshme arkitekturore.
Në arkitekturat e mikroshërbimeve, granulariteti i shërbimit ndikon në testimin, vendosjen, performancën dhe besueshmërinë. Mikroshërbimet shumë të hollësishme zakonisht janë më të lehta për t'u testuar dhe vendosur në mënyrë të pavarur, por ato shpesh përjetojnë performancë më të ulët dhe besueshmëri të përgjithshme të reduktuar për shkak të rritjes së komunikimit ndërshërbim dhe koreografisë më komplekse të shërbimit. Shërbimet e hollësishme shfaqin karakteristika kontrastuese. Ato në përgjithësi ofrojnë qëndrueshmëri dhe besueshmëri më të lartë duke minimizuar mbingarkesën e komunikimit dhe kompleksitetin e koordinimit, por janë më sfiduese për t'u testuar dhe vendosur sepse modifikimet ndikojnë në një fushëveprim më të gjerë funksional. Niveli i duhur i granularitetit të shërbimit përcaktohet nga faktorët nxitës të biznesit. Vendimet arkitekturore zakonisht fillojnë me identifikimin e këtyre faktorëve nxitës dhe më pas me përshtatjen e karakteristikave arkitekturore si performanca, shkallëzueshmëria, besueshmëria ose fleksibiliteti i vendosjes për t'i mbështetur ato.
Hartimi i mikroserviseve në kontekste të kufizuara
Një kontekst i kufizuar, një koncept themelor në dizajnin e drejtuar nga domeni (DDD), përcakton një zonë specifike brenda së cilës një model domeni është i qëndrueshëm dhe i vlefshëm, duke siguruar qartësi dhe ndarje të shqetësimeve. Në arkitekturën e mikroshërbimeve, një kontekst i kufizuar shpesh i përputhet një mikroshërbimi, por kjo marrëdhënie mund të ndryshojë në varësi të qasjes së dizajnit. Një marrëdhënie një-me-një, ku çdo kontekst i kufizuar zbatohet si një mikroshërbim i vetëm, është zakonisht ideale pasi mban kufij të qartë, zvogëlon çiftëzimin dhe mundëson vendosjen dhe shkallëzimin e pavarur. Megjithatë, edhe hartëzime të tjera mund të jenë të përshtatshme: një marrëdhënie një-me-shumë mund të lindë kur një kontekst i kufizuar ndahet në mikroshërbime të shumta për të adresuar shkallëzueshmëri të ndryshme ose nevoja të tjera operacionale, ndërsa një marrëdhënie shumë-me-një mund të konsolidojë kontekste të shumta të kufizuara në një mikroshërbim të vetëm për thjeshtësi ose për të minimizuar mbingarkesën operacionale. Zgjedhja e marrëdhënies duhet të balancojë parimet e DDD me qëllimet e biznesit të sistemit, kufizimet teknike dhe kërkesat operacionale.
