Doja të shkruaja një artikull mbi temën e arkitekturës së mikroshërbimeve për një kohë të gjatë, por dy pika vazhduan të më ndalonin - sa më tej futesha në temë, aq më shumë më dukej se ajo që di është e qartë dhe ajo që unë nuk dija duhet të studiohet dhe studiohet. Nga ana tjetër, mendoj se tashmë ka diçka për të diskutuar në një audiencë të gjerë. Kështu që opinionet alternative janë të mirëseardhura.
Ligji i Conway dhe marrëdhënia midis biznesit, organizatës dhe sistemit të informacionit
Edhe një herë do t'ia lejoj vetes të citoj:
"Çdo organizatë që harton një sistem (në kuptimin e gjerë) do të marrë një dizajn, struktura e të cilit përsërit strukturën e ekipeve në atë organizatë."
- Melvyn Conway, 1967
Për mendimin tim, ky ligj ka më shumë të ngjarë të lidhet me fizibilitetin e organizimit të një biznesi, sesa drejtpërdrejt me sistemin e informacionit. Më lejoni të shpjegoj me një shembull. Le të themi se kemi një mundësi biznesi mjaft të qëndrueshme me një cikël jetësor kaq të gjatë sa ka kuptim të organizohet një sipërmarrje (kjo nuk është një gabim shtypi, por më pëlqen shumë ky term që kam vjedhur) Natyrisht, sistemi mbështetës i këtij biznesi organizativisht dhe procesualisht do të korrespondojnë me këtë biznes .
Orientimi i biznesit të sistemeve të informacionit
Më lejoni të shpjegoj me një shembull. Le të themi se ekziston një mundësi biznesi për të organizuar një biznes që shet pica. Në versionin V1 (le ta quajmë informacion paraprak), kompania ishte një piceri, një arkë dhe një shërbim dërgese. Ky version ishte jetëgjatë në kushte të ndryshueshmërisë së ulët mjedisore. Pastaj versioni 2 erdhi për ta zëvendësuar atë - më i avancuar dhe i aftë për të përdorur një sistem informacioni në thelbin e tij për biznesin me një arkitekturë monolit. Dhe këtu, për mendimin tim, ka thjesht një padrejtësi të tmerrshme në lidhje me monolitet - kinse arkitektura monolitike nuk korrespondon me modelin e biznesit të domenit. Po, nëse do të ishte kështu, sistemi nuk do të ishte në gjendje të funksiononte fare - në kundërshtim me të njëjtin ligj të Conway dhe sensin e shëndoshë. Jo, arkitektura monolit është plotësisht në përputhje me modelin e biznesit në këtë fazë të zhvillimit të biznesit - unë, natyrisht, nënkuptoj fazën kur sistemi tashmë është krijuar dhe vënë në funksion. Është një fakt absolutisht i mrekullueshëm që pavarësisht nga qasja arkitekturore, versioni 3 i arkitekturës së orientuar nga shërbimi dhe versioni N i arkitekturës së mikroshërbimeve do të funksionojnë po aq mirë. Çfarë është kapja?
Gjithçka rrjedh, gjithçka ndryshon, apo janë mikroshërbimet një mjet për të luftuar kompleksitetin?
Përpara se të vazhdojmë, le të shohim disa keqkuptime rreth arkitekturës së mikroshërbimeve.
Përkrahësit e përdorimit të një qasjeje mikroshërbimi shpesh argumentojnë se thyerja e një monoliti në mikroshërbime thjeshton qasjen e zhvillimit duke reduktuar bazën e kodit të shërbimeve individuale. Për mendimin tim, kjo deklaratë është absurditet i plotë. Seriozisht, ndërveprimi i dukshëm brenda një kodi monolit dhe homogjen duket i komplikuar? Nëse do të ishte vërtet kështu, të gjitha projektet fillimisht do të ndërtoheshin si mikroshërbime, ndërkohë që praktika tregon se migrimi nga monolit në mikroshërbime është shumë më i zakonshëm. Kompleksiteti nuk largohet; ai thjesht kalon nga modulet individuale në ndërfaqet (qofshin autobusët e të dhënave, RPC, API ose protokolle të tjera) dhe sistemet e orkestrimit. Dhe kjo është e vështirë!
Avantazhi i përdorimit të një pirg heterogjen është gjithashtu i diskutueshëm. Unë nuk do të argumentoj se kjo është gjithashtu e mundur, por në realitet ndodh rrallë (Duke parë përpara - kjo duhet të ndodhë - por më tepër si pasojë sesa një avantazh).
Cikli i jetës së produktit dhe cikli i jetës së shërbimit
Hidhini një sy tjetër diagramit të mësipërm. Nuk është rastësi që vura re uljen e ciklit jetësor të një versioni të veçantë të një biznesi - në kushtet moderne, është përshpejtimi i kalimit të një biznesi midis versioneve që është vendimtar për suksesin e tij. Suksesi i një produkti përcaktohet nga shpejtësia e testimit të hipotezave të biznesit në të. Dhe këtu, për mendimin tim, qëndron përparësia kryesore e arkitekturës së mikroshërbimeve. Por le të shkojmë me radhë.
Le të kalojmë në fazën tjetër në evolucionin e sistemeve të informacionit - në arkitekturën e orientuar drejt shërbimit të SOA. Pra, në një moment të caktuar ne theksuam në produktin tonë shërbime jetëgjatë - jetëgjatë në kuptimin që kur lëvizni midis versioneve të një produkti, ekziston mundësia që cikli i jetës së shërbimit të jetë më i gjatë se cikli i jetës së versionit të ardhshëm të produktit. Do të ishte logjike të mos i ndryshonim fare - ne Ajo që ka rëndësi është shpejtësia e kalimit në versionin tjetër. Por mjerisht, ne jemi të detyruar të bëjmë ndryshime të vazhdueshme në shërbime - dhe këtu gjithçka funksionon për ne, praktikat e DevOps, kontejnerizimi e kështu me radhë - gjithçka që na vjen në mendje. Por këto nuk janë ende mikroshërbime!
Mikroshërbimet si mjet për të luftuar kompleksitetin... menaxhimi i konfigurimit
Dhe këtu më në fund mund të kalojmë te roli përcaktues i mikroshërbimeve - kjo është një qasje që thjeshton menaxhimin e konfigurimit të produktit. Në mënyrë më të detajuar, funksioni i çdo mikroshërbimi përshkruan saktësisht funksionin e biznesit brenda produktit sipas modelit të domenit - dhe këto janë gjëra që jetojnë jo në një version jetëshkurtër, por në një mundësi biznesi jetëgjatë. Dhe kalimi në versionin tjetër të produktit ndodh fjalë për fjalë pa u vënë re - ju ndryshoni/shtoni një mikroshërbim, dhe ndoshta vetëm skemën e ndërveprimit të tyre, dhe befas e gjeni veten në të ardhmen, duke lënë pas konkurrentët që qajnë që vazhdojnë të kërcejnë midis versioneve të monolitet e tyre. Tani imagjinoni që ka një vëllim mjaft të madh mikroshërbimesh me ndërfaqe të paracaktuara dhe aftësi biznesi. Dhe ju vini dhe ndërtoni strukturën e produktit tuaj nga mikroshërbime të gatshme - thjesht duke vizatuar një diagram, për shembull. Urime - ju keni një platformë - dhe tani mund të tërheqni biznes për veten tuaj. Ëndrrat Ëndrrat.
Gjetjet
- Arkitektura e sistemit duhet të përcaktohet nga cikli i jetës së komponentëve të tij. Nëse një komponent jeton brenda një versioni produkti, nuk ka kuptim të rritet kompleksiteti i sistemit duke përdorur një qasje mikroservice.
- Arkitektura e mikroshërbimit duhet të bazohet në modelin e domenit - sepse mundësia e biznesit është domeni më jetëgjatë
- Praktikat e dorëzimit (praktikat e DevOps) dhe orkestrimi janë një nga më të rëndësishmet për arkitekturën e mikroshërbimeve - për arsye se rritja e shkallës së ndryshimit të komponentëve vendos kërkesa në rritje për shpejtësinë dhe cilësinë e dorëzimit.
Burimi: www.habr.com