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
