Seniai norėjau parašyti straipsnį mikropaslaugų architektūros tema, bet mane nuolat stabdė du dalykai - kuo toliau gilinausi į temą, tuo labiau man atrodė, kad tai, ką žinau, yra akivaizdu, o ką aš ne. t žinoti, kad reikia mokytis ir studijuoti. Kita vertus, manau, kad jau yra apie ką diskutuoti plačioje auditorijoje. Taigi laukiamos alternatyvios nuomonės.
Conway dėsnis ir verslo, organizacijos ir informacinės sistemos santykis
Dar kartą leisiu sau pacituoti:
„Bet kuri organizacija, kurianti sistemą (plačiąja prasme), gaus dizainą, kurio struktūra atkartos tos organizacijos komandų struktūrą.
- Melvynas Conway, 1967 m
Mano nuomone, šis įstatymas labiau susijęs su verslo organizavimo galimybe, o ne tiesiogiai su informacine sistema. Leiskite paaiškinti pavyzdžiu. Tarkime, turime gana stabilias verslo galimybes, kurių gyvavimo ciklas toks ilgas, kad būtų prasminga organizuoti įmonę (tai nėra rašybos klaida, bet man labai patinka šis pavogtas terminas). Natūralu, kad šio verslo palaikymo sistema organizaciniu ir procesiniu požiūriu atitiks šį verslą.
Informacinių sistemų verslo orientacija
Leiskite paaiškinti pavyzdžiu. Tarkime, yra verslo galimybė organizuoti picų pardavimo verslą. V1 versijoje (vadinkime tai išankstine informacija) įmonė buvo picerija, kasos aparatas ir pristatymo tarnyba. Ši versija buvo ilgaamžė mažo aplinkos kintamumo sąlygomis. Tada ją pakeitė 2 versija – pažangesnė ir galinti naudoti monolitinės architektūros informacinę sistemą verslui. Ir čia, mano nuomone, yra tiesiog baisi neteisybė monolitų atžvilgiu - tariamai monolitinė architektūra neatitinka domeno verslo modelio. Taip, jei taip būtų, sistema išvis negalėtų veikti – tai prieštarautų tam pačiam Conway įstatymui ir sveikam protui. Ne, monolitinė architektūra visiškai atitinka verslo modelį šiame verslo plėtros etape – aš, žinoma, turiu galvoje etapą, kai sistema jau sukurta ir pradėta eksploatuoti. Tikrai nuostabus faktas, kad nepaisant architektūrinio požiūrio, tiek į paslaugas orientuotos architektūros 3 versija, tiek mikropaslaugų architektūros versija N veiks vienodai gerai. Koks laimikis?
Viskas teka, viskas keičiasi, o gal mikropaslaugos yra priemonė kovoti su sudėtingumu?
Prieš tęsdami, pažvelkime į keletą klaidingų nuomonių apie mikro paslaugų architektūrą.
Mikropaslaugų metodo naudojimo šalininkai dažnai teigia, kad monolito suskaidymas į mikropaslaugas supaprastina kūrimo metodą, nes sumažėja atskirų paslaugų kodų bazė. Mano nuomone, šis teiginys yra visiška nesąmonė. Rimtai, akivaizdi monolito ir vienalyčio kodo sąveika atrodo sudėtinga? Jei taip tikrai būtų, iš pradžių visi projektai būtų kuriami kaip mikropaslaugos, o praktika rodo, kad migracija nuo monolito prie mikropaslaugų yra daug dažnesnė. Sudėtingumas neišnyksta; jis tiesiog pereina iš atskirų modulių į sąsajas (ar tai būtų duomenų magistralės, RPC, API ir kiti protokolai) ir orkestravimo sistemas. Ir tai yra sunku!
Taip pat abejotinas heterogeninio kamino naudojimo pranašumas. Nesiginčysiu, kad tai taip pat įmanoma, bet iš tikrųjų tai nutinka retai (Žiūrint į priekį - taip turėtų nutikti, bet greičiau kaip pasekmė, o ne pranašumas).
Produkto gyvavimo ciklas ir paslaugos gyvavimo ciklas
Dar kartą pažvelkite į aukščiau pateiktą diagramą. Neatsitiktinai pastebėjau mažėjantį atskiro verslo varianto gyvavimo ciklą – šiuolaikinėmis sąlygomis būtent verslo perėjimo tarp versijų paspartėjimas yra lemiamas jo sėkmei. Produkto sėkmę lemia verslo hipotezių tikrinimo jame greitis. Ir čia, mano nuomone, slypi pagrindinis mikroservisų architektūros pranašumas. Bet eikime eilės tvarka.
Pereikime prie kito informacinių sistemų evoliucijos etapo – į paslaugas orientuotos SOA architektūros. Taigi, tam tikru momentu mes pabrėžėme savo gaminį ilgaamžės paslaugos - ilgaamžė ta prasme, kad judant tarp produkto versijų yra tikimybė, kad paslaugos gyvavimo ciklas bus ilgesnis nei kitos gaminio versijos gyvavimo ciklas. Logiška būtų jų visai nekeisti – mes Svarbus yra perėjimo prie kitos versijos greitis. Bet deja, esame priversti nuolat keisti paslaugas – o čia mums viskas veikia, DevOps praktika, konteinerizavimas ir taip toliau – viskas, kas ateina į galvą. Bet tai vis tiek nėra mikropaslaugos!
Mikropaslaugos kaip priemonė kovoti su sudėtingumu... konfigūracijos valdymas
Ir čia pagaliau galime pereiti prie mikropaslaugų vaidmens – tai metodas, kuris supaprastina produkto konfigūracijos valdymą. Išsamiau kiekvienos mikropaslaugos funkcija tiksliai apibūdina verslo funkciją produkto viduje pagal domeno modelį – ir tai yra dalykai, kurie gyvena ne trumpalaikėje versijoje, o ilgalaikėje verslo galimybėje. O perėjimas prie kitos produkto versijos įvyksta tiesiog nepastebimai – pakeičiate/pridedate vieną mikropaslaugą, o galbūt tik jų sąveikos schemą, ir staiga atsiduriate ateityje, palikdami verkiančius konkurentus, kurie ir toliau šokinėja tarp versijų. jų monolitai. Dabar įsivaizduokite, kad yra gana daug mikro paslaugų su iš anksto nustatytomis sąsajomis ir verslo galimybėmis. O jūs ateini ir susikuriate savo gaminio struktūrą iš jau paruoštų mikroservisų – tiesiog nubraižydami schemą, pavyzdžiui. Sveikiname – turite platformą – ir dabar galite pritraukti verslą sau. Svajonės Svajonės.
išvados
- Sistemos architektūra turėtų būti nulemta jos komponentų gyvavimo ciklo. Jei komponentas yra produkto versijoje, nėra prasmės didinti sistemos sudėtingumą naudojant mikropaslaugų metodą.
- Mikro paslaugų architektūra turėtų būti pagrįsta domeno modeliu, nes verslo galimybė yra ilgiausiai gyvuojantis domenas
- Pristatymo praktika (DevOps praktika) ir orkestravimas yra vienas svarbiausių mikropaslaugų architektūrai – dėl to, kad didėjantis komponentų keitimo greitis kelia didesnius reikalavimus pristatymo greičiui ir kokybei.
Šaltinis: www.habr.com