Kodėl mikropaslaugos gali būti baigtos, nes monolitai grįžta su kerštu

Perėjimas prie mikropaslaugų įsibėgėjo 2010-ųjų pradžioje, kai technologijų įmonės pripažino monolitinės architektūros apribojimus. Tačiau daugelis įmonių, tokių kaip „Amazon“ („Prime Video“, „Invision“, „Istio“ ir „Segment“), grįžta prie monolitinės architektūros. Šiame straipsnyje bus nagrinėjama, kodėl daugeliui organizacijų nepavyksta pereiti prie mikropaslaugų architektūros.

Kas yra monolitas?

Monolitinė architektūra yra nesudėtinga: vartotojas prašo duomenų, o visa verslo logika ir duomenys yra vienoje paslaugoje. Tačiau monolitinės sistemos susiduria su tokiais iššūkiais kaip ribotas mastelio keitimas, sunkumai diegiant naujinimus ir pažeidžiamumas dėl atskirų gedimo taškų.

Kad tai išspręstų, daugelis organizacijų bandė pereiti prie mikropaslaugomis pagrįstos architektūros, kad išnaudotų tokius pranašumus kaip abstrakcija ir inkapsuliavimas, greitesnis diegimas, lengvesnė priežiūra ir glaudesnis kiekvienos paslaugos derinimas su komandos nuosavybe.

Kodėl mikropaslaugos?

Idealioje mikro paslaugų architektūroje kiekvienas verslo domenas veikia kaip atskira paslauga su savo duomenų baze. Ši sąranka suteikia tokių pranašumų kaip geresnis mastelio keitimas, lankstumas ir atsparumas. Apsvarstykite žemiau pateiktą diagramą.

Realybė

Tačiau naujausios tendencijos rodo, kad daugelis įmonių nuo to atsitraukia ir laikosi monolitinės architektūros. Taip yra todėl, kad realiame pasaulyje sunku pasiekti tokį harmonijos lygį. Tikrovė dažnai atrodo taip, kaip toliau pateikta diagrama.

Buvo žinoma, kad perkėlimas į mikro paslaugų architektūrą sukelia sudėtingą paslaugų sąveiką, žiedinius skambučius, duomenų vientisumo problemas ir, tiesą sakant, beveik neįmanoma visiškai atsikratyti monolito. Aptarkime, kodėl kai kurios iš šių problemų kyla perėjus į mikropaslaugų architektūrą.

Neteisingi domeno ribos

Idealiu atveju viena paslauga turėtų apimti vieną ar daugiau užbaigtų verslo domenų, kad kiekvienas domenas būtų savarankiškas paslaugos viduje. Domenas niekada neturėtų būti padalintas į kelias paslaugas, nes tai gali sukelti paslaugų tarpusavio priklausomybę. Šioje diagramoje parodyta, kaip vienoje paslaugoje gali būti vienas ar keli ištisi domenai, kad būtų išlaikytos aiškios ribos.

Sudėtingose ​​realaus pasaulio sistemose nustatyti domeno ribas gali būti sudėtinga, ypač kai duomenys tradiciškai buvo konceptualizuoti tam tikru būdu. Šioje diagramoje parodyta, kaip realaus pasaulio sistemos dažnai atrodo mikro paslaugų architektūroje, kai ribos nėra iš anksto apibrėžtos arba inžinieriai prideda naujų paslaugų, neatsižvelgdami į domeno ribas.

Jei domenai nėra tiksliai apibrėžti, didėja priklausomybė nuo kitų paslaugų, todėl kyla daug problemų:

• Žiedinės priklausomybės arba per daug skambučių: kai paslaugos yra tarpusavyje susijusios, reikia dažnai keistis duomenimis.
• Duomenų vientisumo problemos: padalijus vieną domeną paslaugoms, giliai susieti duomenys išskaidomi keliose paslaugose.
• Neaiški komandos nuosavybė: kelioms komandoms gali tekti bendradarbiauti sutampančiose srityse, todėl gali atsirasti neefektyvumas ir painiava.

Giliai susieti duomenys ir funkcionalumas

Monolitinėje architektūroje klientai dažnai praleidžia paskirtas sąsajas ir tiesiogiai pasiekia duomenų bazę, nes vienoje kodų bazėje sunku užtikrinti inkapsuliavimą. Tai gali paskatinti kūrėjus naudoti sparčiuosius klavišus, ypač jei sąsajos neaiškios arba atrodo sudėtingos. Laikui bėgant tai sukuria klientų tinklą, glaudžiai susietą su konkrečiomis duomenų bazės lentelėmis ir verslo logika.

Pereinant prie mikro paslaugų architektūros, kiekvieną klientą reikia atnaujinti, kad jis veiktų su naujomis paslaugų API. Tačiau dėl to, kad klientai yra taip susieti su monolito verslo logika, perkėlimo metu jų logiką reikia pertvarkyti.

Šių priklausomybių išaiškinimas nepažeidžiant esamų funkcijų užtrunka. Kai kurie klientų atnaujinimai dažnai vėluoja dėl darbo sudėtingumo, todėl kai kurie klientai po perkėlimo vis dar naudojasi monolito duomenų baze. Norėdami to išvengti, inžinieriai gali sukurti naujus duomenų modelius naujoje tarnyboje, bet išlaikyti esamus modelius monolite. Kai modeliai yra glaudžiai susieti, duomenys ir funkcijos suskaidomi tarp paslaugų, o tai sukelia daugybę skambučių tarp tarnybų ir duomenų vientisumo problemų.

Duomenų perkėlimas

Duomenų perkėlimas yra vienas sudėtingiausių ir rizikingiausių elementų pereinant prie mikropaslaugų. Labai svarbu tiksliai ir visiškai perkelti visus svarbius duomenis į naujas mikropaslaugas. Daugelis perkėlimų sustoja šiame etape dėl sudėtingumo, tačiau sėkmingas duomenų perkėlimas yra labai svarbus norint suvokti mikropaslaugų naudą. Įprasti iššūkiai apima:

• Duomenų vientisumas ir nuoseklumas: klaidos perkėlimo metu gali sukelti duomenų praradimą arba neatitikimus.
• Duomenų apimtis: didelių duomenų kiekių perkėlimas gali pareikalauti daug išteklių ir atimti daug laiko.
• Prastovos ir veiklos tęstinumas: dėl duomenų perkėlimo gali prireikti prastovų, o tai gali sutrikdyti verslo veiklą. Sklandus perėjimas su minimaliu vartotojo poveikiu yra labai svarbus.
• Testavimas ir patvirtinimas: norint užtikrinti, kad perkelti duomenys būtų tikslūs, išsamūs ir gerai veiktų naujoje tarnyboje, reikia atlikti griežtą testavimą.

Išvada

Mikro paslaugų architektūra gali atrodyti patraukliai, tačiau pereiti nuo monolito yra sudėtinga. Daugelis įmonių atsidūrė pusiaukelėje, o tai padidina sistemos sudėtingumą ir sukelia duomenų vientisumo problemų, cirkuliarinę priklausomybę ir neaiškią komandos nuosavybę. Nesugebėjimas realiame pasaulyje išnaudoti visų mikropaslaugų privalumų yra priežastis, kodėl daugelis įmonių grįžta prie monolitinio požiūrio.

Supriya Lal yra grupės „Yelp“ prekybos platformos organizacijos technologijų vadovas.