{"id":92810,"date":"2020-08-31T07:42:09","date_gmt":"2020-08-31T05:42:09","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/vybor-arhitekturnogo-stilya-chast-1"},"modified":"2020-08-31T07:42:09","modified_gmt":"2020-08-31T05:42:09","slug":"vybor-arhitekturnogo-stilya-chast-1","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/vybor-arhitekturnogo-stilya-chast-1","title":{"rendered":"Arhitektuuristiili valik (osa 1)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Tere, Habr. Praegu on OTUS-s avatud uus kursuse voor \u201eTarkvara arhitekt\u201c<\/a><\/noindex>. Kursuse alguse eel tahaksin jagada teiega oma autoriartiklit.<\/i><\/b><\/p>\n

<\/p>\n

Sissejuhatus<\/h2>\n

\nArhitektuuristiili valimine on \u00fcks p\u00f5hitehnilisi otsuseid teabe s\u00fcsteemi loomisel. Selles artiklite seerias soovin uurida populaarseimaid rakenduste arhitektuuristiile ja vastata k\u00fcsimusele, millal on m\u00f5ni arhitektuuristiil k\u00f5ige eelistatum. Kirjutamise k\u00e4igus p\u00fc\u00fcan esitada loogilise ahela, mis selgitab arhitektuuristiilide arengut monoliitidest mikroteenusteni.
\n<\/a><\/noindex><\/p>\n

Veidi ajalugu<\/h2>\n

\nKui proovite k\u00fcsida arendajatelt: \u201eMiks on mikroteenused vajalikud?\u201c, siis saate v\u00e4ga erinevaid vastuseid. Kuulete, et mikroteenused parandavad skaleeritavust, lihtsustavad koodi m\u00f5istmist, parandavad rikke taluvust, m\u00f5nikord v\u00f5ite kuulda, et nad v\u00f5imaldavad \u201ekoodi puhastada\u201c. Vaatame ajaloole tagasi, et m\u00f5ista, millist eesm\u00e4rki j\u00e4lgis mikroteenuste teke.<\/p>\n

L\u00fchidalt \u00f6eldes, mikroteenused meie praeguses m\u00f5istes tekkisid j\u00e4rgmisel viisil: 2011. aastal t\u00e4helepanu juhtides erinevate ettev\u00f5tete t\u00f6\u00f6dele m\u00e4rkis James Lewis uue \u00abmicro-app\u00bb mustri ilmumist, mis optimeeris SOA-d teenuste k\u00e4ivitamise kiirusest l\u00e4htuvalt. M\u00f5ni aeg hiljem, 2012. aastal, nimetati arhitektuuri tipps\u00fcndmuses muster mikroteenuseks \u00fcmber. Seega oli mikroteenuste juurutamise algne eesm\u00e4rk parendada nii-\u00f6elda turuleminemise aega<\/b>.<\/p>\n

Mikroteenuseid k\u00e4sitleti 2015. aastal \u00abhype\u00bb laine peal. Paljude uuringute kohaselt ei m\u00f6\u00f6dunud \u00fckski konverents ilma mikroteenuseid k\u00e4sitleva ettekandeta. Veelgi enam, m\u00f5ned konverentsid olid p\u00fchendatud ainult mikroteenustele. Praegu alustavad paljud projektid selle arhitektuuristiiliga, ja kui projekt sisaldab tohutut hulka vanakoodi, siis toimub kindlasti aktiivne migratsioon mikroteenustele.<\/p>\n

Hoolimata \u00fclaltoodust suudab praegu veel \u00fcsna v\u00e4hene arendaja m\u00e4\u00e4ratleda m\u00f5iste \u00abmikroteenus\u00bb. Kuid sellest r\u00e4\u00e4gime natuke hiljem...<\/p>\n

Monoliit<\/h2>\n

\nMikroteenustele vastanduv arhitektuuristiil on monoliitne (v\u00f5i \"k\u00f5ik \u00fches\"). Monoliidist r\u00e4\u00e4kida ilmselt ei olegi m\u00f5tet, seega loetlen kohe selle arhitektuuristiili puudused, mis viisid edasise arhitektuuristiilide arenguni: suurus, sidusus, juurutamine, skaleeritavus, usaldusv\u00e4\u00e4rsus ja j\u00e4ikus. Allpool pakun v\u00e4lja, et tutvuda iga puudusega eraldi.<\/p>\n

Suurus<\/h3>\n

\nMonoliit on v\u00e4ga suur. Ja tavaliselt suhtleb ta v\u00e4ga suure andmebaasiga. Rakendus muutub liiga suureks, et seda saaks \u00fche arendaja poolt p\u00f5him\u00f5tteliselt m\u00f5ista. Monoliidiga saavad h\u00e4sti t\u00f6\u00f6tada vaid need, kes on selle koodiga piisavalt aega veetnud, samas kui algajad kulutavad palju aega \u00fcritades monoliiti m\u00f5ista ning ei pruugi sellest l\u00f5puks aru saada. T\u00fc\u00fcpiliselt on monoliidi t\u00f6\u00f6tamise juures alati mingisugune \"tinglik\" senior, kes tunneb monoliiti enam-v\u00e4hem h\u00e4sti ja hoiab uutel arendajatel k\u00e4ed t\u00f6\u00f6sse. Loomulikult on selline tinglik senior ainus vigu tegeva punkt ning tema lahkumine v\u00f5ib viia monoliidi hukule. <\/p>\n

Seotus<\/h3>\n

\nMonoliit on nagu suur porikogum, mille muutmine v\u00f5ib p\u00f5hjustada ettearvamatuid tagaj\u00e4rgi. Muutuste tegemine \u00fches kohas v\u00f5ib kahjustada monoliiti teises (nagu \u00f6eldakse, \"krapsutas k\u00f5rva, ja terve asi lagunes\"). See on tingitud sellest, et monoliidi komponendid omavad v\u00e4ga keerulisi ja peamiselt mitte-ilmselgeid seoseid.<\/p>\n

Juurutamine<\/h3>\n

\nMonoliidi juurutamine, arvestades komponentide vahelisi keerulisi seoseid, on pikk protsess, mis sisaldab oma rituaali. Tegu on rituaaliga, mida tavaliselt ei ole t\u00e4ielikult standardiseeritud ja edastatakse \"suust suhu\". <\/p>\n

Skaleeritavus<\/h3>\n

\nMonoliidi moodulid v\u00f5ivad omada \u00fcksteisega vastandlikke ressursin\u00e4ude, seet\u00f5ttu tuleb leida kompromiss riistvara osas. Kujutage ette, et teie monoliit koosneb teenustest A ja B. Teenus A on n\u00f5udlik ketta suuruse osas, samas kui teenus B n\u00f5uab rohkem RAM-i. Sel juhul peab masin, millele monoliit paigaldatakse, toetama m\u00f5lema teenuse n\u00f5udeid, v\u00f5i tuleb k\u00e4sitsi teatud teenus v\u00e4lja l\u00fclitada.<\/p>\n

Veel klassikaline n\u00e4ide: teenus A on tuntum kui teenus B, seega soovite, et teenuseid A oleks 100 ja teenuseid B 10. J\u00e4llegi on kaks v\u00f5imalust: kas paigaldame 100 t\u00e4isfunktsionaalset monoliiti v\u00f5i peame m\u00f5nest neist k\u00e4sitsi teenuseid B v\u00e4lja l\u00fclitama. <\/p>\n

Usaldusv\u00e4\u00e4rsus<\/h3>\n

\nKuna k\u00f5ik teenused on koos, siis kui monoliit kokku kukub, kukuvad k\u00f5ik teenused korraga. Tegelikult ei pruugi see olla sedav\u00f5rd halb \u2013 osalisi rikkeid jaotatud s\u00fcsteemis ei esine, kuid teisest k\u00fcljest v\u00f5ite funktsionaalsuse vea t\u00f5ttu, mida kasutab 0,001% kasutajatest, kaotada k\u00f5ik oma s\u00fcsteemi kasutajad. <\/p>\n

J\u00f5hkrus<\/h3>\n

\n\u0412\u0432\u0438\u0434\u0443 \u0440\u0430\u0437\u043c\u0435\u0440\u0430 \u043c\u043e\u043d\u043e\u043b\u0438\u0442\u0430 \u0442\u044f\u0436\u0435\u043b\u043e \u043f\u0435\u0440\u0435\u0439\u0442\u0438 \u043d\u0430 \u043d\u043e\u0432\u044b\u0435 \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u0438. \u041a\u0430\u043a \u0441\u043b\u0435\u0434\u0441\u0442\u0432\u0438\u0435, \u043e\u0442\u0434\u0435\u043b\u044c\u043d\u043e\u0439 \u0437\u0430\u0434\u0430\u0447\u0435\u0439 \u0432\u044b\u0440\u0438\u0441\u043e\u0432\u044b\u0432\u0430\u0435\u0442 \u0443\u0434\u0435\u0440\u0436\u0430\u043d\u0438\u0435 \u0442\u043e\u0433\u043e \u0441\u0430\u043c\u043e\u0433\u043e \u0443\u0441\u043b\u043e\u0432\u043d\u043e\u0433\u043e senior’\u0430. \u0412\u044b\u0431\u0440\u0430\u043d\u043d\u044b\u0439 \u043d\u0430 \u0441\u0442\u0430\u0440\u0442\u0435 \u043f\u0440\u043e\u0435\u043a\u0442\u0430 \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u0447\u0435\u0441\u043a\u0438\u0439 \u0441\u0442\u0435\u043a \u043c\u043e\u0436\u0435\u0442 \u0441\u0442\u0430\u0442\u044c \u0431\u043b\u043e\u043a\u043e\u043c, \u043f\u0440\u0435\u043f\u044f\u0442\u0441\u0442\u0432\u0443\u044e\u0449\u0438\u043c \u0440\u0430\u0437\u0432\u0438\u0442\u0438\u044e \u043f\u0440\u043e\u0434\u0443\u043a\u0442\u0430. <\/p>\n

Kokkuv\u00f5te<\/h2>\n

\nJ\u00e4rgmine kord r\u00e4\u00e4gime sellest, kuidas inimesed proovisid m\u00e4rgitud probleeme lahendada, liikudes komponentide ja SOA juurde.<\/p>\n

\"Arhitektuuristiili<\/a><\/noindex><\/p>\n

\n

Loe edasi:<\/h4>\n

<\/p>\n