Arhitektuuristiili valik (osa 1)

Tere, Habr. Just nüüd on OTUSis avatud uus kursuse voog. „Software Architect“. Kursuse alguses tahan jagada teiega oma autorilugu.

Sissejuhatus

Arhitektuuristiili valik on üks peamisi tehnilisi otsuseid teabe süsteemi loomisel. Selles artiklite seerias käsitleme kõige populaarsemaid rakenduste arhitektuuristiile ja vastame küsimusele, millal on milline arhitektuuristiil kõige eelistatum. Käsitlen loogilist ahelat, mis selgitab arhitektuuristiilide arengut monoliitsetest mikroteenustele.

Enne kui liigume edasi

Kui proovite küsida arendajatelt: „Miks on mikroteenused vajalikud?“, siis saate kõige erinevamaid vastuseid. Kuulete, et mikroteenused parandavad skaleeritavust, lihtsustavad koodi mõistmist, suurendavad usaldusväärsust, vahel võite kuulda, et nad võimaldavad „koodi puhastada“. Vaatame ajaloos tagasi, et mõista, millist eesmärki mikroteenuste loomine järgnes.

Lühidalt öeldes tekkisid mikroteenused meie tänapäevases mõistes järgmiselt: 2011. aastal märkis James Lewis, analüüsides erinevate ettevõtete töid, uue mustri „micro-app“ tekkimist, mis optimeeris SOA teenuste juurutamise kiirusest. Veidi hiljem, 2012. aastal, nimetati arhitektuurisummitil muster mikroteenuseks. Seega oli mikroteenuste rakendamise algne eesmärk parandada kurikuulsat time to market.

Mikroteenuste laine oli 2015. aastal väga populaarne. Mõnede uuringute kohaselt ei möödunud ükski konverents ilma mikroteenuste teemalise ettekandeta. Veel enam, mõned konverentsid keskendusid ainult mikroteenustele. Praegu algavad väga paljud projektid selle arhitektuuristiili rakendamisega, ja kui projekt sisaldab suures mahus pärandkoodi, siis tõenäoliselt toimub aktiivne üleminek mikroteenustele.

Hoolimata eeltoodust suudab veel üsna väike arv arendajaid määratleda mõistet „mikroteenus“. Kuid sellest räägime natuke hiljem...

Monoliit

Mikroteenustele vastanduv arhitektuuristiil on monoliit (või „kõik ühes“). Selles stiilis pole mõtet rääkida monoliidist, seetõttu loetlen kohe selle arhitektuuristiili puudused, mis initsieerisid edasise arhitektuuristiilide arengu: suurus, seotus, juurutamine, skaleeritavus, usaldusväärsus ja jäikus. Allpool tutvustan kõiki puudusi eraldi.

Suurus

Monoliit on väga suur. Ja see suhtleb tavaliselt väga suure andmebaasiga. Rakendus muutub liiga suureks, et seda saaks üksi mõista. Monoliidiga saavad hästi töötada ainult need, kes on selle koodiga piisavalt kaua aega veetnud, samas kui algajad kulutavad väga palju aega proovides monoliidiga toime tulla, ja ei ole kindel, et nad saavad sellega jagu. Tüüpiliselt on monoliidi töös alati mingi „tinglik“ vanem, kes tunneb monoliiti enam-vähem hästi ja hoiab uued arendajad aasta või pooleteise jooksul käpuli. Loomulikult on selline tinglik vanem ainsaks rikke punktiks, ja tema lahkumine võib tuua kaasa monoliidi hävimise.

Seos

Monoliit esindab „suur must kera“ (big ball of mud), mille muutmine võib tuua ettearvamatuid tagajärgi. Muute ühes kohas, võib kahjustada monoliiti teises kohas (just see „kõrva sügamine, *@ kukkus maha“). See on seotud sellega, et monoliidi komponendid omavad väga keerulisi ja mis kõige tähtsam, mitte selgeid seoseid.

Tõhustamine

Monoliidi tõhustamine on oma komponentide vaheliste keeruliste seoste tõttu pikk protsess koos oma rituaaliga. Selline rituaal ei ole tavaliselt täielikult standardiseeritud ja seda edastatakse "suust suhu".

Skaleeritavus

Monoliidi moodulitel võivad olla konfliktseid vajadusi ressursside osas, mistõttu on vajalik leida kompromiss riistvara osas. Kujutage ette, et teie monoliit koosneb teenustest A ja B. Teenus A nõuab suurt kõvakettamahtu, samas kui teenus B nõuab palju mälu. Sellisel juhul peab masin, kuhu monoliit paigaldatakse, toetama mõlema teenuse nõudmisi, või tuleb käsitsi üks teenustest välja lülitada.

Veel üks näide (klassikalisem): teenus A on palju populaarsem kui teenus B, seega soovite, et teenuseid A oleks 100 ja teenuseid B oleks 10. Taaskord kaks varianti: kas paigaldame 100 täisfunktsionaalset monoliiti või tuleb mõnes neist käsitsi teenused B välja lülitada.

Usaldusväärsus

Kuna kõik teenused on koos, siis kui monoliit ebaõnnestub, ebaõnnestuvad kõik teenused korraga. Tegelikult pole see võib-olla nii halb, kuna jaotatud süsteemis ei esine osalisi tõrkeid, kuid teisest küljest võite kaotada kõik oma süsteemi kasutajad, sest tõrge funktsionaalsuses, mida kasutab 0,001% kasutajatest.

Kangus

Monoliidi suuruse tõttu on keeruline üle minna uutele tehnoloogiatele. Selle tagajärjel tõuseb eraldi ülesanne hoida alles tegemisolevat tingimuslikku senior'i. Projekti alguses valitud tehnoloogia virn võib osutuda takistuseks toote arengule.

Kokkuvõte

Järgmine kord räägime sellest, kuidas inimesed on püüdnud neid probleeme lahendada, liikudes komponentide ja SOA suunas.

Loe edasi:

• Miks SQL Server ei garanteeri tulemuste sortimist ilma ORDER BY-ta
• Arhitektuur arendajatele ja administreerijatele: kellele millised oskused on vajalikud?

Allikas: habr.com