Tere, Habr. Praegu on OTUS-s avatud uus kursuse voor . Kursuse alguse eel tahaksin jagada teiega oma autoriartiklit.
Sissejuhatus
Arhitektuuristiili valimine on üks põhitehnilisi otsuseid teabe süsteemi loomisel. Selles artiklite seerias soovin uurida populaarseimaid rakenduste arhitektuuristiile ja vastata küsimusele, millal on mõni arhitektuuristiil kõige eelistatum. Kirjutamise käigus püüan esitada loogilise ahela, mis selgitab arhitektuuristiilide arengut monoliitidest mikroteenusteni.
Veidi ajalugu
Kui proovite küsida arendajatelt: „Miks on mikroteenused vajalikud?“, siis saate väga erinevaid vastuseid. Kuulete, et mikroteenused parandavad skaleeritavust, lihtsustavad koodi mõistmist, parandavad rikke taluvust, mõnikord võite kuulda, et nad võimaldavad „koodi puhastada“. Vaatame ajaloole tagasi, et mõista, millist eesmärki jälgis mikroteenuste teke.
Lühidalt öeldes, mikroteenused meie praeguses mõistes tekkisid järgmisel viisil: 2011. aastal tähelepanu juhtides erinevate ettevõtete töödele märkis James Lewis uue «micro-app» mustri ilmumist, mis optimeeris SOA-d teenuste käivitamise kiirusest lähtuvalt. Mõni aeg hiljem, 2012. aastal, nimetati arhitektuuri tippsündmuses muster mikroteenuseks ümber. Seega oli mikroteenuste juurutamise algne eesmärk parendada nii-öelda turuleminemise aega.
Mikroteenuseid käsitleti 2015. aastal «hype» laine peal. Paljude uuringute kohaselt ei möödunud ükski konverents ilma mikroteenuseid käsitleva ettekandeta. Veelgi enam, mõned konverentsid olid pühendatud ainult mikroteenustele. Praegu alustavad paljud projektid selle arhitektuuristiiliga, ja kui projekt sisaldab tohutut hulka vanakoodi, siis toimub kindlasti aktiivne migratsioon mikroteenustele.
Hoolimata ülaltoodust suudab praegu veel üsna vähene arendaja määratleda mõiste «mikroteenus». Kuid sellest räägime natuke hiljem...
Monoliit
Mikroteenustele vastanduv arhitektuuristiil on monoliitne (või "kõik ühes"). Monoliidist rääkida ilmselt ei olegi mõtet, seega loetlen kohe selle arhitektuuristiili puudused, mis viisid edasise arhitektuuristiilide arenguni: suurus, sidusus, juurutamine, skaleeritavus, usaldusväärsus ja jäikus. Allpool pakun välja, et tutvuda iga puudusega eraldi.
Suurus
Monoliit on väga suur. Ja tavaliselt suhtleb ta väga suure andmebaasiga. Rakendus muutub liiga suureks, et seda saaks ühe arendaja poolt põhimõtteliselt mõista. Monoliidiga saavad hästi töötada vaid need, kes on selle koodiga piisavalt aega veetnud, samas kui algajad kulutavad palju aega üritades monoliiti mõista ning ei pruugi sellest lõpuks aru saada. Tüüpiliselt on monoliidi töötamise juures alati mingisugune "tinglik" senior, kes tunneb monoliiti enam-vähem hästi ja hoiab uutel arendajatel käed töösse. Loomulikult on selline tinglik senior ainus vigu tegeva punkt ning tema lahkumine võib viia monoliidi hukule.
Seotus
Monoliit on nagu suur porikogum, mille muutmine võib põhjustada ettearvamatuid tagajärgi. Muutuste tegemine ühes kohas võib kahjustada monoliiti teises (nagu öeldakse, "krapsutas kõrva, ja terve asi lagunes"). See on tingitud sellest, et monoliidi komponendid omavad väga keerulisi ja peamiselt mitte-ilmselgeid seoseid.
Juurutamine
Monoliidi juurutamine, arvestades komponentide vahelisi keerulisi seoseid, on pikk protsess, mis sisaldab oma rituaali. Tegu on rituaaliga, mida tavaliselt ei ole täielikult standardiseeritud ja edastatakse "suust suhu".
Skaleeritavus
Monoliidi moodulid võivad omada üksteisega vastandlikke ressursinäude, seetõttu tuleb leida kompromiss riistvara osas. Kujutage ette, et teie monoliit koosneb teenustest A ja B. Teenus A on nõudlik ketta suuruse osas, samas kui teenus B nõuab rohkem RAM-i. Sel juhul peab masin, millele monoliit paigaldatakse, toetama mõlema teenuse nõudeid, või tuleb käsitsi teatud teenus välja lülitada.
Veel klassikaline näide: teenus A on tuntum kui teenus B, seega soovite, et teenuseid A oleks 100 ja teenuseid B 10. Jällegi on kaks võimalust: kas paigaldame 100 täisfunktsionaalset monoliiti või peame mõnest neist käsitsi teenuseid B välja lülitama.
Usaldusväärsus
Kuna kõik teenused on koos, siis kui monoliit kokku kukub, kukuvad kõik teenused korraga. Tegelikult ei pruugi see olla sedavõrd halb – osalisi rikkeid jaotatud süsteemis ei esine, kuid teisest küljest võite funktsionaalsuse vea tõttu, mida kasutab 0,001% kasutajatest, kaotada kõik oma süsteemi kasutajad.
Jõhkrus
Monoliidi suure suuruse tõttu on keeruline üle minna uutele tehnoloogiatele. Selle tagajärjel kerkib esile eraldi ülesanne hoida endal seda nn senior'i. Projekti alguses valitud tehnoloogia tase võib takistada tootearendust.
Kokkuvõte
Järgmine kord räägime sellest, kuidas inimesed proovisid märgitud probleeme lahendada, liikudes komponentide ja SOA juurde.
Loe edasi:
Allikas: habr.com
