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.
Herë e fundit, ndamë mendime mbi llojet e ndryshme të monoliteve dhe përdorimin e komponenteve për ndërtimin e tyre, përfshirë komponentët e mbledhjes dhe ata të shpërndarjes. Ne e shqyrtuam arkitekturën e orientuar rreth shërbimeve.
Tani, më në fund, do të përcaktojmë karakteristikat kryesore të arkitekturës mikroshërbimore.
Marrëdhënia e arkitekturave
Është e rëndësishme të kuptohet se, bazuar në të dhënat në artikujt e mëparshëm, çdo shërbim është një komponent, por jo çdo shërbim është një mikroshërbim.
Karakteristikat e arkitekturës mikroshërbimore
Karakteristikat kryesore të arkitekturës mikroshërbimore janë:
- Organizimi sipas mundësive të biznesit (Organized around Business Capabilities)
- Produkte, jo projekte (Products not Projects)
- Pikat e mençura të hyrjes dhe kanalet e thjeshta (Smart endpoints and dumb pipes)
- Qeverisja e decentralizuar (Decentralized Governance)
- Menaxhimi i decentralizuar i të dhënave (Decentralized Data Management)
- Automatizimi i infrastrukturës (Infrastructure Automation)
- Sigurimi nga dështimet (Design for failure)
- Arkitektura me evoluim (Evolutionary Design)
Pika e parë vjen nga arkitektura e orientuar rreth shërbimeve, sepse mikroshërbimet janë një rast i veçantë i shërbimeve. Pikat e tjera meritojnë shqyrtim të veçantë.
Organizimi sipas mundësive të biznesit (Organized around Business Capabilities)
Tani është e rëndësishme të kujtojmë ligjin e Conway-t: organizatat që krijojnë sisteme organizojnë arkitekturën e saj, që pasqyron strukturën e bashkëpunimit brenda këtyre organizatave. Një shembull është krijimi i një kompajluesi: një ekip prej shtatë personash krijoi një kompajlues me shtatë kalime, ndërsa një ekip prej pesë personash krijoi një kompajlues me pesë kalime.
Nëse flasim për monolite dhe mikroshërbime, atëherë, nëse zhvillimi organizohet nga departamentet funksionale (backend, frontend, administruesit e bazave të të dhënave), atëherë kjo rezulton në një monolit klasik.
Për të krijuar mikroshërbime, ekipet duhet të organizohen sipas mundësive të biznesit (ekipi i porosive, ekipet e dërgesave, ekipi i katalogut). Kjo organizatë do t'u mundësojë ekipeve të fokusohen në krijimin e pjesëve specifike të aplikacionit.
Produkte, jo projekte (Products not Projects)
Qasja projektuale, në të cilën ekipi kalon funksionalitetin e zhvilluar në ekipe të tjera rreth arkitekturës mikroshërbimore, nuk është e përshtatshme. Ekipi duhet të mbajë sistemin gjatë gjithë ciklit të tij të jetës. Kompania Amazon, një nga pionierët e aplikimit të mikroshërbimeve, deklaroi: "ti krijon produktin dhe ti e drejton atë" ("you build, you run it"). Qasja e produktit lejon ekipin të ndiejë nevojat e biznesit.
Pikat e mençura të hyrjes dhe kanalet e thjeshta (Smart endpoints and dumb pipes)
Arkitektura SOA i kushtoi shumë vëmendje kanaleve të komunikimit, veçanërisht Bus-it të Shërbimeve të Ndërmarrjes (Enterprise Service Bus). Kjo shpesh çon në Erroneous Spaghetti Box, që do të thotë se kompleksiteti i monolitit kalon në kompleksitetin e lidhjeve midis shërbimeve. Në arkitekturën mikroshërbimore përdoren vetëm mënyra të thjeshta për ndërveprim.
Qeverisja e decentralizuar (Decentralized Governance)
Vendimet kyçe për mikroshërbimet duhet të merren nga ata që realisht zhvillojnë mikroshërbimet. Këtu, vendimet kyçe nënkuptojnë zgjedhjen
të gjuhëve të programimit, metodologjinë e shpërndarjes, kontratat e interfaceve publike etj.
Menaxhimi i decentralizuar i të dhënave (Decentralized Data Management)
Qasja standarde, në të cilën aplikacioni mbështetet në një bazë të vetme të dhënash, nuk mund të marrë parasysh specifikat e çdo shërbimi të veçantë. MSA parashikon menaxhimin e decentralizuar të të dhënave, deri në përdorimin e teknologjive të ndryshme.
Automatizimi i infrastrukturës (Infrastructure Automation)
MSA mbështet proceset e shpërndarjes dhe furnizimit të vazhdueshëm. Kjo është e mundur vetëm përmes automatizimit të proceseve. Në këtë rast, shpërndarja e një numri të madh shërbimesh nuk duket më e frikshme. Procesi i shpërndarjes duhet të bëhet i mërzitshëm. Aspekti i dytë lidhet me menaxhimin e shërbimeve në mjedisin e produktit. Pa automatizim, menaxhimi i proceseve të nisura në mjedise të ndryshme bëhet i pamundur.
Sigurimi nga dështimet (Design for failure)
Shërbimet e shumta të MSA janë të ndjeshme ndaj dështimeve. Në këtë rast, trajtimi i gabimeve në një sistem të shpërndarë është një detyrë jo triviale. Arkitektura e aplikacioneve duhet të jetë e qëndrueshme ndaj këtyre dështimeve. Rebeka Parsons vlerëson se është shumë e rëndësishme që ne nuk përdorim më as ndërveprimin brenda procesit midis shërbimeve, por për lidhje përdorim HTTP, i cili nuk është as afër kaq i besueshëm.
Arkitektura me evoluim (Evolutionary Design)
Arkitektura e sistemit MSA duhet të evoluojë. Preferohet që të kufizohen ndryshimet e nevojshme brenda kufijve të një shërbimi. Duhet gjithashtu të merret parasysh ndikimi në shërbime të tjera. Qasja tradicionale është të përpiqesh ta zgjidhësh këtë problem përmes menaxhimit të versioneve, por MSA parashikon përdorimin e menaxhimit të versioneve si një masë ekstremale.
si masë ekstreme.
Përfundimi
Pas së gjithash, mund të përmblidhet se çfarë janë mikroshtetet. Arkitektura e mikroshteteve është një qasje për zhvillimin e një aplikacioni të veçantë si një grup shërbimesh të vogla, secila prej të cilave punon në procesin e saj të vet dhe ndërvepron përmes mekanizmave të lehtë, shpesh përmes API-së të burimeve HTTP. Këto shërbime ndërtohen mbi mundësitë e biznesit dhe mund të implementohen në mënyrë të pavarur me një mekanizëm të plotë
automatizimi i implementimit. Ka një nivel minimal të menaxhimit qendror të këtyre shërbimeve, që mund të shkruhen në gjuhë të ndryshme programimi dhe të përdorin teknologji të ndryshme të ruajtjes së të dhënave.
Burimi: habr.com
