Përshëndetje, Habr. Sot vazhdoj një seri botimesh që kam shkruar posaçërisht për fillimin e një rryme të re të kursit. .
Paraqitje
Zgjedhja e stilit arkitektonik është një nga vendimet themelore teknike gjatë ndërtimit të një sistemi informacioni. Në këtë seri artikujsh, unë propozoj të analizoj stilet më të njohura arkitekturore për aplikimet e ndërtimit dhe t'i përgjigjem pyetjes se kur stili arkitektonik është më i preferuari. Në procesin e prezantimit, do të përpiqem të vizatoj një zinxhir logjik që shpjegon zhvillimin e stileve arkitekturore nga monolitet në mikroshërbime.
Herën e fundit folëm për llojet e ndryshme të monoliteve dhe përdorimin e komponentëve për ndërtimin e tyre, si për komponentët e ndërtimit ashtu edhe për komponentët e vendosjes. Ne e kuptojmë arkitekturën e orientuar drejt shërbimit.
Tani më në fund do të përcaktojmë karakteristikat kryesore të një arkitekture mikroservice.
Marrëdhënia e arkitekturave
Është e nevojshme të kuptohet 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ë mikroshërbim.
Karakteristikat e Arkitekturës së Microservice
Karakteristikat kryesore të arkitekturës së mikroshërbimeve janë:
- Organizuar rreth Aftësive të Biznesit
- Produkte jo projekte
- Pika fundore të zgjuara dhe tuba memecë
- Qeverisja e Decentralizuar
- Menaxhimi i decentralizuar i të dhënave
- Automatizimi i Infrastrukturës
- Dizajn për dështim
- Arkitektura me zhvillim evolucionar (Evolutionary Design)
Pika e parë vjen nga arkitektura e orientuar drejt shërbimit sepse mikroshërbimet janë një rast i veçantë shërbimesh. Pika të tjera meritojnë shqyrtim të veçantë.
Organizuar rreth Aftësive të Biznesit
Tani është e nevojshme të kujtojmë ligjin e Conway: organizatat që krijojnë sisteme organizojnë arkitekturën e saj, duke kopjuar strukturën e ndërveprimit brenda këtyre organizatave. Si shembull, mund të kujtojmë rastin e krijimit të një përpiluesi: një ekip prej shtatë personash zhvilloi një përpilues me shtatë kalime dhe një ekip prej pesësh zhvilloi një përpilues me pesë kalime.
Nëse po flasim për monolite dhe mikroshërbime, atëherë nëse zhvillimi organizohet nga departamente funksionale (backend, frontend, administratorët e bazës së të dhënave), atëherë marrim një monolit klasik.
Për të marrë mikroshërbime, ekipet duhet të organizohen sipas aftësive të biznesit (porositë, dërgesat, ekipi i katalogut). Kjo organizatë do t'i lejojë ekipet të përqendrohen në ndërtimin e pjesëve specifike të aplikacionit.
Produkte jo projekte
Një qasje projekti në të cilën një ekip transferon funksionalitetin e zhvilluar tek ekipet e tjera është plotësisht i papërshtatshëm në rastin e një arkitekture mikroservice. Ekipi duhet të mbështesë sistemin gjatë gjithë ciklit të tij jetësor. Amazon, një nga liderët në zbatimin e mikroshërbimeve, deklaroi: "ti ndërton, ti e drejton". Qasja e produktit lejon ekipin të ndiejë nevojat e biznesit.
Pika fundore të zgjuara dhe tuba memecë
Arkitektura SOA i kushtoi vëmendje të madhe kanaleve të komunikimit, në veçanti Autobusit të Shërbimit të Ndërmarrjeve. E cila shpesh çon në Erroreous Spaghetti Box, domethënë, kompleksiteti i monolitit kthehet në kompleksitet të lidhjeve midis shërbimeve. Arkitektura e mikroservisit përdor vetëm metoda të thjeshta komunikimi.
Qeverisja e Decentralizuar
Vendimet kryesore në lidhje me mikroshërbimet duhet të merren nga njerëzit që në të vërtetë zhvillojnë mikroshërbimet. Këtu, vendimet kryesore nënkuptojnë zgjedhje
gjuhët e programimit, metodologjia e vendosjes, kontratat e ndërfaqes publike, etj.
Menaxhimi i decentralizuar i të dhënave
Qasja standarde, në të cilën aplikacioni mbështetet në një bazë të dhënash të vetme, nuk mund të marrë parasysh specifikat e secilit shërbim specifik. MSA përfshin menaxhimin e decentralizuar të të dhënave, duke përfshirë përdorimin e teknologjive të ndryshme.
Automatizimi i Infrastrukturës
MSA mbështet proceset e vazhdueshme të vendosjes dhe shpërndarjes. Kjo mund të arrihet vetëm duke automatizuar proceset. Në të njëjtën kohë, vendosja e një numri të madh shërbimesh nuk duket më si diçka e frikshme. Procesi i vendosjes duhet të bëhet i mërzitshëm. Aspekti i dytë lidhet me menaxhimin e shërbimit në një mjedis produkti. Pa automatizim, menaxhimi i proceseve që funksionojnë në mjedise të ndryshme operimi bëhet i pamundur.
Dizajn për dështim
Shërbime të shumta MSA janë të prirura për dështim. Në të njëjtën kohë, trajtimi i gabimeve në një sistem të shpërndarë nuk është një detyrë e parëndësishme. Arkitektura e aplikacionit duhet të jetë elastike ndaj dështimeve të tilla. Rebecca Parsons mendon se është shumë e rëndësishme që ne të mos përdorim më as komunikim në proces ndërmjet shërbimeve; përkundrazi, ne përdorim HTTP për komunikim, i cili nuk është pothuajse aq i besueshëm.
Arkitektura me zhvillim evolucionar (Evolutionary Design)
Arkitektura e sistemit MSA duhet të zhvillohet në mënyrë evolucionare. Është e këshillueshme që të kufizohen ndryshimet e nevojshme në kufijtë e një shërbimi të vetëm. Duhet të merret parasysh edhe ndikimi në shërbimet e tjera. Qasja tradicionale është të përpiqeni ta zgjidhni këtë problem me versionim, por MSA sugjeron përdorimin e versionimit në
si mjet i fundit.
Përfundim
Pas të gjitha sa më sipër, ne mund të formulojmë se çfarë janë mikroshërbimet. Arkitektura e mikroshërbimit është një qasje për zhvillimin e një aplikacioni të vetëm si një koleksion shërbimesh të vogla, secila funksionon në procesin e vet dhe ndërvepron përmes mekanizmave të lehtë, shpesh API-të e burimeve HTTP. Këto shërbime janë ndërtuar mbi aftësitë e biznesit dhe mund të vendosen në mënyrë të pavarur duke përdorur plotësisht
mekanizmi i automatizuar i 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: www.habr.com