Unë kam dëshiruar të shkruaj një artikull mbi arkitekturën mikroshërbimeve për një kohë të gjatë, por dy momente gjithmonë më ndaluan — sa më thellë të shkoja në temë, aq më shumë më dukej se ajo që di është e qartë, ndërsa ajo që nuk di do të më duhet të eksploroj dhe më shumë. Nga ana tjetër, mendoj se tashmë ka shumë për të diskutuar edhe në një audiencë më të gjerë. Pra, mendimet alternative janë të mirëpritura.
Ligji i Conway-t dhe lidhja mes biznesit, organizatës dhe sistemit informatik
Përsëri do të lejoj vetes të citoj:
«Çdo organizatë që projektin një sistem (në kuptimin e gjerë) do të marrë një dizajn, struktura e të cilit kopjon strukturën e ekipeve në këtë organizatë»
— Melvyn Conway, 1967
Sipas mendimit tim, ky ligj lidhet më shumë me arsyeshmërinë e organizimit të biznesit se sa drejtpërdrejt me sistemin informativ. Le të shpjegoj me një shembull. Supozoni se kemi një mundësi biznesi mjaft stabile me një cikël jetësor të tillë sa ka kuptim të organizojmë një nismë (kjo nuk është një shkrim i gabuar, por më pëlqen shumë ky term që e kam marrë). Natyrisht, sistemi që mbështet këtë biznes do të jetë organizativisht dhe procesualisht në përputhje me këtë biznes.
Orientimi drejt biznesit i sistemeve informative
Le të shpjegoj me një shembull. Supozoni ekzistencën e një mundësie biznesi për organizimin e një biznesi të shitjes së picave. Në versionin V1 (ta quajmë para-informativ), kompania përbënte një piceri, një kasë dhe një shërbim dërgimi. Ky version ishte i qëndrueshëm në kushte të ulta të ndryshueshmërisë së botës përreth. Më pas erdhi versioni 2 — më i avancuar dhe me aftësi për të përdorur një sistem informativ si bazë për biznesin me një arkitekturë monolitike. Dhe këtu, sipas mendimit tim, lind një padrejtësi e tmerrshme ndaj monoliteve — arkitektura e pretenduar monolitike nuk i përgjigjet modelit të biznesit. Po sikur të ishte kështu, sistemi nuk do të mund të funksiononte fare - në kundërshtim me të njëjtin ligj të Conway-t dhe shëndetin e arsyes. Jo, arkitektura monolitike i përket plotësisht modelit të biznesit në këtë fazë të zhvillimit të biznesit — natyrisht, kam parasysh fazën kur sistemi është tashmë i ndërtuar dhe vendosur në funksion. Një fakt krejt i mrekullueshëm është se, pavarësisht nga qasja arkitekturore, arkitektura e orientuar nga shërbimet versioni 3 dhe arkitektura e mikroshërbimeve versioni N do të funksionojnë po aq mirë. Çfarë është sfida?
Gjithçka rrjedh, gjithçka ndryshon, ose mikroshërbimet janë një mjet për të luftuar kompleksitetin?
Para se të vazhdojmë, le të shqyrtojmë disa keqkuptime në lidhje me arkitekturën e mikroshërbimeve.
Përkrahësit e përdorimit të qasjes mikroshërbimore shpesh thonë se ndarja e monolitit në mikroshërbime e thjeshton qasjen në zhvillim përmes zvogëlimit të bazës së kodit të shërbimeve të veçanta. Në mendimin tim, ky pohim është plotësisht nonsense. Seriousisht, a duket vërtet e komplikuar interaksioni brenda një monoliti dhe kodit homogjen? Nëse do të ishte kështu, të gjitha projektet do të ndaheshin fillimisht si mikroshërbime, ndërkohë që praktika tregon se migrimi nga monoliti në mikroshërbime është shumë më i zakonshëm. Kompleksiteti nuk zhduket, ai thjesht kalon nga modul të veçanta në ndërfaqe (qoftë autobusa të të dhënave, RPC, API dhe protokolle të tjera) dhe sisteme orkestruese. Dhe kjo është e komplikuar!
Përfitimi i përdorimit të një stoku heterogjen gjithashtu është i dyshimtë. Nuk do të diskutoj se kjo mund të ndodhë, por në realitet është rrallë e hasur (Përveç kësaj - duhet të ndodhë - por më tepër si një pasojë se sa një përfitim).
Cikli i jetës së produktit dhe cikli i jetës së shërbimit
Shikoni përsëri diagramën më sipër. Nuk e kam shënuar rastësisht ciklin e jetës së zvogëluar të njëversionit të biznesit - në kushtet moderne, pikërisht përshpejtimi i kalimit të biznesit midis versioneve është përcaktues për suksesin e tij. Suksesi i produktit përcaktohet nga shpejtësia e verifikimit të hipotezave të biznesit në të.. Dhe këtu, sipas mendimit tim, është e fshehur përparësia kyçe e arkitekturës mikroshërbimeve. Por le të shkojmë me radhë.
Të kalojmë në shkallën tjetër të evolucionit të sistemeve informacioni - në arkitekturën e orientuar ndaj shërbimeve SOA. Pra, në një moment të caktuar, ne ndamë në produktin tonë shërbime afatgjata — afatgjata në kuptimin se, kur kalojmë midis versioneve të produktit, ka shanse që cikli i jetës së shërbimit të jetë më i gjatë se cikli i jetës së versionit të radhës të produktit. Do të ishte logjike t'i lëshim ato siç janë — ne kemi gjithashtu rëndësi pikërisht këtu për shpejtësinë e kalimit në versionin e ardhshëm. Por fatkeqësisht, jemi të detyruar të bëjmë ndryshime të vazhdueshme në shërbime - dhe këtu na punohet gjithçka, praktikë DevOps, kontenjerizim, dhe të tjera - çdo gjë që na vie në mend. Por akoma, kjo nuk janë mikroshërbime!
Mikroshërbimet si një mjet për të luftuar kompleksitetin... menaxhimin e konfiguracionit
Tani mund të kalojmë në rolin përcaktues të mikroshërbimeve — një qasje që thjeshton menaxhimin e konfiguracionit të produktit. Në të vërtetë, funksioni i çdo mikroshërbimi përshkruan funksionin e biznesit brenda produktit sipas modelit domëthanës — dhe këto janë gjëra që nuk jetojnë në versione të përkohshme, por në mundësi biznesi të qëndrueshme. Kalimi në versionin e ardhshëm të produktit ndodh literalisht pa u vënë re — ju ndryshoni/ shtoni një mikroshërbim, ndoshta thjesht strukturën e ndërveprimit dhe papritmas jeni në të ardhmen, duke lënë pas konkurrentët që vazhdojnë të kërcenin mes versioneve të monoliteve të tyre. Tani imagjinoni një sasi të mjaftueshme mikroshërbimesh me ndërfaqe dhe mundësi biznesi të paracaktuar. Ju vini dhe krijoni strukturën e produktit tuaj nga mikroshërbimet e gatshme — thjesht duke vizatuar një diagram, për shembull. Urime — tani keni një platformë — dhe tani mund të krijoni biznesin tuaj. Ëndrrat, ëndrrat.
Përfundimet
- Arkitektura e sistemit duhet të përcaktohet nga cikli i jetës së komponentëve të përfshirë në të. Nëse një komponent jeton brenda versionit të produktit, nuk ka kuptim të rritet kompleksiteti i sistemit duke aplikuar qasjen mikros services.
- Arkitektura mikros services duhet të bazohet në modelin e domenit, sepse mundësia e biznesit është fusha më e qëndrueshme.
- Praktikat e dorëzimit (praktikat DevOps) dhe orkestrimi kanë një rëndësi të madhe për arkitekturën mikros services, sepse rritja e shpejtësisë në ndryshimin e komponentëve kërkon një rritje në shpejtësinë dhe cilësinë e dorëzimit.
Burimi: habr.com
