Sveiki, habr. Registracija į naują kursų srautą šiuo metu vyksta OTUS . Kursų pradžios išvakarėse noriu pasidalinti su jumis savo originaliu straipsniu.
įvedimas
Architektūrinio stiliaus pasirinkimas yra vienas esminių techninių sprendimų kuriant informacinę sistemą. Šiame straipsnių cikle siūlau išanalizuoti populiariausius pastatų architektūros stilius ir atsakyti į klausimą, kada kuris architektūros stilius yra tinkamiausias. Pristatymo metu pabandysiu nubrėžti loginę grandinę, paaiškinančią architektūros stilių raidą nuo monolitų iki mikropaslaugų.
Truputis istorijos
Jei bandysite paklausti kūrėjų: „Kam mums reikalingos mikropaslaugos?“, gausite įvairių atsakymų. Išgirsite, kad mikropaslaugos pagerina mastelio keitimą, daro kodą lengviau suprantamą, pagerina atsparumą gedimams, o kartais išgirsite, kad jos leidžia „išvalyti kodą“. Pažvelkime į istoriją, kad suprastume mikropaslaugų atsiradimo tikslą.
Trumpai tariant, mikropaslaugos mūsų dabartiniu supratimu atsirado taip: 2011 m. Jamesas Lewisas, analizuodamas įvairių įmonių darbą, atkreipė dėmesį į naujos „mikroprogramėlės“ modelio atsiradimą, kuris optimizavo SOA paspartindamas paslaugos. Kiek vėliau, 2012 m., architektūros viršūnių susitikime, modelis buvo pervadintas į mikroservisą. Taigi pradinis mikropaslaugų diegimo tikslas buvo pagerinti liūdnai pagarsėjusį laikas į rinką.
Mikropaslaugos buvo ant ažiotažo bangos 2015 m. Kai kurių tyrimų duomenimis, nei viena konferencija neapsiėjo be pranešimo mikropaslaugų tema. Be to, kai kurios konferencijos buvo skirtos tik mikropaslaugoms. Šiais laikais daugelis projektų pradeda naudoti šį architektūrinį stilių, o jei projekte yra daugybė senojo kodo, greičiausiai yra aktyviai vykdoma migracija į mikropaslaugas.
Nepaisant to, kas išdėstyta pirmiau, gana mažas kūrėjų skaičius vis dar gali apibrėžti „mikropaslaugos“ sąvoką. Bet apie tai pakalbėsime šiek tiek vėliau...
Monolitas
Mikropaslaugoms kontrastuojantis architektūrinis stilius yra monolitas (arba viskas viename). Turbūt nėra prasmės nupasakoti, kas yra monolitas, todėl iš karto išvardinsiu šio architektūrinio stiliaus trūkumus, kurie ir inicijavo tolimesnę architektūrinių stilių plėtrą: dydį, jungiamumą, išdėstymą, mastelį, patikimumą ir standumą. Žemiau siūlau pažvelgti į kiekvieną iš trūkumų atskirai.
Dydis
Monolitas yra labai didelis. Ir dažniausiai bendrauja su labai didele duomenų baze. Programa tampa per didelė, kad vienas kūrėjas galėtų ją suprasti. Tik tie, kurie daug laiko praleido dirbdami su šiuo kodu, gali gerai dirbti su monolitu, o pradedantieji praleis daug laiko bandydami išsiaiškinti monolitą ir nėra garantijos, kad jie tai išsiaiškins. Dažniausiai dirbant su monolitu visada atsiranda koks nors „sąlyginis“ senjoras, kuris daugiau mažiau gerai išmano monolitą ir per pusantrų metų numuša rankas kitiems naujiems kūrėjams. Natūralu, kad toks sąlyginis senjoras yra vienintelis nesėkmės taškas, o jo pasitraukimas gali sukelti monolito mirtį.
Ryšys
Monolitas yra „didelis purvo kamuolys“, kurio pokyčiai gali sukelti nenuspėjamų pasekmių. Vienoje vietoje atlikę pakeitimus galite sugadinti monolitą kitoje (tas pats „pasiraižė ausį, *@ nukrito“). Taip yra dėl to, kad monolito komponentai turi labai sudėtingus ir, svarbiausia, neakivaizdžius ryšius.
Diegimas
Monolito įrengimas dėl sudėtingų jo komponentų santykių yra ilgas procesas su savo ritualu. Toks ritualas paprastai nėra visiškai standartizuotas ir perduodamas „žodžiu“.
Mastelis
Monolitiniai moduliai gali turėti prieštaringų išteklių poreikių, todėl reikia padaryti kompromisą dėl techninės įrangos. Įsivaizduokite, kad turite monolitą, susidedantį iš A ir B paslaugų. Paslauga A reikalauja standžiojo disko dydžio, o paslauga B – RAM. Tokiu atveju arba mašina, kurioje sumontuotas monolitas, turi palaikyti abiejų paslaugų reikalavimus, arba teks rankiniu būdu, dirbtinai išjungti vieną iš paslaugų.
Kitas pavyzdys (klasikiškesnis): paslauga A yra daug populiaresnė nei paslauga B, todėl norisi, kad būtų 100 paslaugų A ir 10 paslaugų B. Vėlgi, du variantai: arba diegiame 100 pilnaverčių monolitų, arba kai kuriuose. paslaugas B teks išjungti rankiniu būdu.
Patikimumas
Kadangi visos paslaugos yra kartu, jei monolitas krenta, tada visos paslaugos krenta iš karto. Tiesą sakant, tai gal ir nėra taip blogai, bent dalinių gedimų paskirstytoje sistemoje nebus, bet kita vertus, dėl funkcionalumo klaidos, kurią naudoja 0.001% vartotojų, galite prarasti visus vartotojus. jūsų sistemos.
Inercija
Dėl monolito dydžio sunku pereiti prie naujų technologijų. Dėl to išlaikyti tą patį senjorą yra atskira užduotis. Projekto pradžioje pasirinktas technologijų krūvas gali tapti bloku, trukdančiu plėtoti produktą.
išvada
Kitą kartą pakalbėsime apie tai, kaip žmonės bandė išspręsti šias problemas pereidami prie komponentų ir SOA.
Skaityti daugiau:
Šaltinis: www.habr.com