Tere, habr. Registreerumine uuele kursuse voogudele on praegu avatud OTUSes . Kursuse alguse eelõhtul tahan teiega jagada oma algset artiklit.
Sissejuhatus
Arhitektuuristiili valik on infosüsteemi ehitamisel üks fundamentaalseid tehnilisi otsuseid. Selles artiklite sarjas teen ettepaneku analüüsida ehitusrakenduste kõige populaarsemaid arhitektuuristiile ja vastata küsimusele, millal on kõige eelistatavam arhitektuuristiil. Esitluse käigus püüan joonestada loogilise ahela, mis selgitab arhitektuuristiilide arengut monoliitidest mikroteenusteni.
Veidi ajalugu
Kui proovite arendajatelt küsida: "Miks me vajame mikroteenuseid?", saate erinevaid vastuseid. Kuulete, et mikroteenused parandavad skaleeritavust, muudavad koodi lihtsamini mõistetavaks, parandavad veataluvust ja mõnikord saate kuulda, et need võimaldavad teil "koodi puhastada". Vaatame ajalugu, et mõista mikroteenuste tekkimise eesmärki.
Lühidalt, meie praeguses arusaamises tekkisid mikroteenused järgmiselt: 2011. aastal juhtis James Lewis erinevate ettevõtete tööd analüüsides tähelepanu uue "mikrorakenduse" mustri tekkimisele, mis optimeeris SOA-d, et kiirendada selle kasutuselevõttu. teenuseid. Veidi hiljem, 2012. aastal, arhitektuuri tippkohtumisel nimetati muster ümber mikroteenuseks. Seega oli mikroteenuste juurutamise esialgne eesmärk kurikuulsa täiustamine aega turule.
Mikroteenused olid 2015. aastal hype lainel. Mõnede uuringute kohaselt ei jäänud ükski konverents läbi ilma mikroteenuste teemalise aruandeta. Lisaks olid mõned konverentsid pühendatud ainult mikroteenustele. Tänapäeval hakatakse seda arhitektuuristiili kasutama paljudes projektides ja kui projekt sisaldab tonnide viisi pärandkoodi, siis tõenäoliselt tegeletakse aktiivselt ka mikroteenustele üleminekuga.
Vaatamata kõigele ülaltoodule suudab mikroteenuse mõiste siiski määratleda üsna väike arv arendajaid. Aga sellest räägime veidi hiljem...
Monoliit
Mikroteenustele vastandav arhitektuuristiil on monoliit (või kõik-ühes). Tõenäoliselt pole mõtet öelda, mis on monoliit, seega loetleksin kohe selle arhitektuuristiili puudused, mis algatasid arhitektuuristiilide edasise arendamise: suurus, ühenduvus, kasutuselevõtt, mastaapsus, töökindlus ja jäikus. Allpool teen ettepaneku vaadata iga puudust eraldi.
Suurus
Monoliit on väga suur. Ja tavaliselt suhtleb see väga suure andmebaasiga. Rakendus muutub liiga suureks, et üks arendaja sellest üldse aru saaks. Monoliidiga saavad hästi töötada ainult need, kes on selle koodi kallal palju aega veetnud, samas kui algajad kulutavad palju aega monoliidi väljaselgitamiseks ja pole mingit garantiid, et nad selle välja mõtlevad. Tavaliselt on monoliidiga töötades alati mõni “tinglik” seenior, kes monoliiti enam-vähem hästi tunneb ja poolteise aasta jooksul teistele uutele arendajatele käed lööb. Loomulikult on selline tingimuslik vanem üksainus ebaõnnestumise punkt ja tema lahkumine võib viia monoliidi surmani.
Ühendus
Monoliit on “suur mudapall”, mille muutused võivad viia ettearvamatute tagajärgedeni. Ühes kohas muudatusi tehes võid teises kohas monoliiti kahjustada (sama “sa kriimustasid kõrva, *@ kukkus ära”). See on tingitud asjaolust, et monoliidi komponentidel on väga keerulised ja, mis kõige tähtsam, mitteilmnevad seosed.
Juurutamine
Monoliidi kasutuselevõtt on selle komponentide keerukate suhete tõttu pikk protsess, millel on oma rituaal. Selline rituaal ei ole tavaliselt täielikult standardiseeritud ja seda antakse edasi "suuliselt".
Skaalautuvus
Monoliitmoodulitel võivad olla vastuolulised ressursivajadused, mis nõuavad riistvara osas kompromissi tegemist. Kujutage ette, et teil on monoliit, mis koosneb teenustest A ja B. Teenus A nõuab kõvaketta suurust ja teenus B nõuab RAM-i. Sel juhul peab masin, millele monoliit on paigaldatud, toetama mõlema teenuse nõudeid või peate ühe teenuse käsitsi, kunstlikult keelama.
Teine näide (klassikalisem): teenus A on palju populaarsem kui teenus B, nii et soovite, et seal oleks 100 teenust A ja 10 teenust B. Jällegi on kaks võimalust: kas võtame kasutusele 100 täisväärtuslikku monoliiti või siis mõnel teenused B tuleb käsitsi keelata.
Usaldusväärsus
Kuna kõik teenused asuvad koos, siis kui monoliit langeb, langevad kõik teenused korraga. Tegelikult ei pruugi see nii hull olla, vähemalt hajutatud süsteemis ei esine osalisi tõrkeid, kuid teisest küljest võite funktsionaalsuse vea tõttu, mida kasutab 0.001% kasutajatest, kaotada kõik kasutajad teie süsteemist.
Inerts
Monoliidi suuruse tõttu on uutele tehnoloogiatele üleminek keeruline. Sellest tulenevalt on sama vanuri hoidmine eraldi ülesanne. Projekti alguses valitud tehnoloogiavirn võib muutuda blokkiks, mis takistab toote arengut.
Järeldus
Järgmisel korral räägime sellest, kuidas inimesed on püüdnud neid probleeme lahendada, liikudes komponentide ja SOA juurde.
Loe rohkem:
Allikas: www.habr.com