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.
Herën e kaluar folëm për llojet e ndryshme të monoliteve dhe për përdorimin e komponentëve në ndërtimin e tyre, si të komponentëve të ndërtimit ashtu edhe të komponentëve të vendosjes. Gjithashtu sqaruam arkitekturën e orientuar drejt shërbimeve.
Tani më në fund do të përcaktojmë karakteristikat kryesore të arkitekturës me mikrosherbime.
Marrëdhënia mes arkitekturave
Duhet kuptuar se, bazuar në përkufizimet e dhëna në artikujt e mëparshëm, çdo shërbim është një komponent, por jo çdo shërbim është një mikrosherbim.
Karakteristikat e arkitekturës me mikrosherbime
Karakteristikat kryesore të arkitekturës me mikrosherbime janë:
- Organizim sipas aftësive të biznesit (Organized around Business Capabilities)
- Produkte, jo projekte (Products not Projects)
- Pika hyrëse të zgjuara dhe kanale të thjeshta (Smart endpoints and dumb pipes)
- Menaxhim i decentralizuar (Decentralized Governance)
- Menaxhim i decentralizuar i të dhënave (Decentralized Data Management)
- Automatizimi i infrastrukturës (Infrastructure Automation)
- Projektim për dështimin (Design for failure)
- Arkitekturë me zhvillim evolucionar (Evolutionary Design)
Pika e parë vjen nga arkitektura e orientuar drejt shërbimeve, sepse mikrosherbimet janë një rast i veçantë i shërbimeve. Pikat e tjera meritojnë shqyrtim të veçantë.
Organizim sipas aftësive të biznesit (Organized around Business Capabilities)
Tani duhet të kujtojmë ligjin e Conway-t: organizatat që krijojnë sisteme ndërtojnë arkitekturën e tyre duke pasqyruar strukturën e ndërveprimit brenda këtyre organizatave. Si shembull mund të kujtojmë rastin e krijimit të një kompajleri: një ekip prej shtatë personash zhvilloi një kompajler me shtatë kalime, ndërsa një ekip prej pesë personash zhvilloi një kompajler me pesë kalime.
Nëse flasim për monolite dhe mikrosherbime, atëherë kur zhvillimi organizohet sipas departamenteve funksionale (backend, frontend, administratorët e bazës së të dhënave), rezultati është një monolit klasik.
Për të krijuar mikrosherbime, ekipet duhet të organizohen sipas aftësive të biznesit (ekipi i porosive, dërgesave, katalogut). Një organizim i tillë u jep ekipeve mundësinë të përqendrohen në krijimin e pjesëve konkrete të aplikacionit.
Produkte, jo projekte (Products not Projects)
Qasja e projektit, ku ekipi ia dorëzon funksionalitetin e zhvilluar ekipeve të tjera, nuk është aspak e përshtatshme në rastin e arkitekturës me mikrosherbime. Ekipi duhet ta mbështesë sistemin gjatë gjithë ciklit të tij jetësor. Amazon, një nga flamurtarët e zbatimit të mikrosherbimeve, ka deklaruar: «ju e ndërtoni produktin dhe po ju vetë e vini në punë» («you build, you run it»). Qasja e orientuar te produkti i ndihmon ekipit të kuptojë nevojat e biznesit.
Pika hyrëse të zgjuara dhe kanale të thjeshta (Smart endpoints and dumb pipes)
Arkitektura SOA i kushtonte vëmendje të madhe kanaleve të komunikimit, veçanërisht Enterprise Service Bus (autobusi i shërbimeve të ndërmarrjes). Kjo shpesh çon në Erroneous Spaghetti Box, domethënë kompleksiteti i monolitit transferohet në kompleksitetin e lidhjeve ndërmjet shërbimeve. Në arkitekturën me mikrosherbime përdoren vetëm mënyra të thjeshta ndërveprimi.
Menaxhim i decentralizuar (Decentralized Governance)
Vendimet kyçe pĂ«r mikrosherbimet duhet tâi marrin njerĂ«zit qĂ« i zhvillojnĂ« realisht ato. KĂ«tu, me vendime kyçe nĂ«nkuptohet zgjedhja e
gjuhëve të programimit, metodologjive të vendosjes, kontratave të ndërfaqeve publike etj.
Menaxhim i decentralizuar i të dhënave (Decentralized Data Management)
Qasja standarde, ku aplikacioni mbështetet në një bazë të vetme të dhënash, nuk mund të marrë parasysh veçoritë e çdo shërbimi të veçantë. MSA nënkupton menaxhim të decentralizuar të të dhënave, deri edhe në përdorimin e teknologjive të ndryshme.
Automatizimi i infrastrukturës (Infrastructure Automation)
MSA mbështet proceset e vendosjes dhe ofrimit të vazhdueshëm. Kjo mund të realizohet vetëm përmes automatizimit të proceseve. Në këtë rast, vendosja e një numri të madh shërbimesh nuk duket më si diçka e frikshme. Procesi i vendosjes duhet të bëhet rutinë. Aspekti i dytë lidhet me menaxhimin e shërbimeve në mjedisin e produktit. Pa automatizim, menaxhimi i proceseve të nisura në mjedise të ndryshme operative bëhet i pamundur.
Projektim për dështimin (Design for failure)
Shërbimet e shumta të MSA janë të prira ndaj dështimeve. Ndërkohë, trajtimi i gabimeve në një sistem të shpërndarë është një detyrë aspak triviale. Arkitektura e aplikacioneve duhet të jetë rezistente ndaj këtyre dështimeve. Rebecca Parsons e konsideron shumë të rëndësishme faktin që ne nuk përdorim më as ndërveprim brenda të njëjtit proces mes shërbimeve; në vend të kësaj, për komunikim përdorim HTTP, i cili nuk është aspak po aq i besueshëm.
Arkitekturë me zhvillim evolucionar (Evolutionary Design)
Arkitektura e njĂ« sistemi MSA duhet tĂ« zhvillohet nĂ« mĂ«nyrĂ« evolutive. ĂshtĂ« e dĂ«shirueshme qĂ« ndryshimet e nevojshme tĂ« kufizohen brenda kufijve tĂ« njĂ« shĂ«rbimi tĂ« vetĂ«m. Po ashtu, duhet tĂ« merret parasysh ndikimi te shĂ«rbimet e tjera. Qasja tradicionale konsiston nĂ« pĂ«rpjekjen pĂ«r ta zgjidhur kĂ«tĂ« problem me ndihmĂ«n e versionimit, por MSA nĂ«nkupton pĂ«rdorimin e versionimit si
masë të fundit.
PĂ«rfundim
Pas gjithë sa u tha më sipër, mund të përkufizohet se çfarë janë mikroshërbimet. Arkitektura e mikroshërbimeve është një qasje për zhvillimin e një aplikacioni të veçantë në formën e një grupi shërbimesh të vogla, secila prej të cilave funksionon në procesin e vet dhe ndërvepron përmes mekanizmave të lehtë, shpesh përmes API-ve të burimeve HTTP. Këto shërbime ndërtohen mbi funksionalitete biznesi dhe mund të vendosen në mënyrë të pavarur me ndihmën e një mekanizmi plotësisht
të automatizuar të vendosjes. Ekziston një nivel minimal i menaxhimit të centralizuar të këtyre shërbimeve, të cilat mund të shkruhen në gjuhë të ndryshme programimi dhe të përdorin teknologji të ndryshme të ruajtjes së të dhënave.
Burimi: habr.com
