{"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. Just n\u00fc\u00fcd on OTUSis avatud uus kursuse voog. \u201eSoftware Architect\u201c<\/a><\/noindex>. Kursuse alguses tahan jagada teiega oma autorilugu.<\/i><\/b><\/p>\n

<\/p>\n

Sissejuhatus<\/h2>\n

\nArhitektuuristiili valik on \u00fcks peamisi tehnilisi otsuseid teabe s\u00fcsteemi loomisel. Selles artiklite seerias k\u00e4sitleme k\u00f5ige populaarsemaid rakenduste arhitektuuristiile ja vastame k\u00fcsimusele, millal on milline arhitektuuristiil k\u00f5ige eelistatum. K\u00e4sitlen loogilist ahelat, mis selgitab arhitektuuristiilide arengut monoliitsetest mikroteenustele.
\n<\/a><\/noindex><\/p>\n

Enne kui liigume edasi<\/h2>\n

\nKui proovite k\u00fcsida arendajatelt: \u201eMiks on mikroteenused vajalikud?\u201c, siis saate k\u00f5ige erinevamaid vastuseid. Kuulete, et mikroteenused parandavad skaleeritavust, lihtsustavad koodi m\u00f5istmist, suurendavad usaldusv\u00e4\u00e4rsust, vahel v\u00f5ite kuulda, et nad v\u00f5imaldavad \u201ekoodi puhastada\u201c. Vaatame ajaloos tagasi, et m\u00f5ista, millist eesm\u00e4rki mikroteenuste loomine j\u00e4rgnes.<\/p>\n

L\u00fchidalt \u00f6eldes tekkisid mikroteenused meie t\u00e4nap\u00e4evases m\u00f5istes j\u00e4rgmiselt: 2011. aastal m\u00e4rkis James Lewis, anal\u00fc\u00fcsides erinevate ettev\u00f5tete t\u00f6id, uue mustri \u201emicro-app\u201c tekkimist, mis optimeeris SOA teenuste juurutamise kiirusest. Veidi hiljem, 2012. aastal, nimetati arhitektuurisummitil muster mikroteenuseks. Seega oli mikroteenuste rakendamise algne eesm\u00e4rk parandada kurikuulsat time to market<\/b>.<\/p>\n

Mikroteenuste laine oli 2015. aastal v\u00e4ga populaarne. M\u00f5nede uuringute kohaselt ei m\u00f6\u00f6dunud \u00fckski konverents ilma mikroteenuste teemalise ettekandeta. Veel enam, m\u00f5ned konverentsid keskendusid ainult mikroteenustele. Praegu algavad v\u00e4ga paljud projektid selle arhitektuuristiili rakendamisega, ja kui projekt sisaldab suures mahus p\u00e4randkoodi, siis t\u00f5en\u00e4oliselt toimub aktiivne \u00fcleminek mikroteenustele.<\/p>\n

Hoolimata eeltoodust suudab veel \u00fcsna v\u00e4ike arv arendajaid m\u00e4\u00e4ratleda m\u00f5istet \u201emikroteenus\u201c. Kuid sellest r\u00e4\u00e4gime natuke hiljem...<\/p>\n

Monoliit<\/h2>\n

\nMikroteenustele vastanduv arhitektuuristiil on monoliit (v\u00f5i \u201ek\u00f5ik \u00fches\u201c). Selles stiilis pole m\u00f5tet r\u00e4\u00e4kida monoliidist, seet\u00f5ttu loetlen kohe selle arhitektuuristiili puudused, mis initsieerisid edasise arhitektuuristiilide arengu: suurus, seotus, juurutamine, skaleeritavus, usaldusv\u00e4\u00e4rsus ja j\u00e4ikus. Allpool tutvustan k\u00f5iki puudusi eraldi.<\/p>\n

Suurus<\/h3>\n

\nMonoliit on v\u00e4ga suur. Ja see suhtleb tavaliselt v\u00e4ga suure andmebaasiga. Rakendus muutub liiga suureks, et seda saaks \u00fcksi m\u00f5ista. Monoliidiga saavad h\u00e4sti t\u00f6\u00f6tada ainult need, kes on selle koodiga piisavalt kaua aega veetnud, samas kui algajad kulutavad v\u00e4ga palju aega proovides monoliidiga toime tulla, ja ei ole kindel, et nad saavad sellega jagu. T\u00fc\u00fcpiliselt on monoliidi t\u00f6\u00f6s alati mingi \u201etinglik\u201c vanem, kes tunneb monoliiti enam-v\u00e4hem h\u00e4sti ja hoiab uued arendajad aasta v\u00f5i pooleteise jooksul k\u00e4puli. Loomulikult on selline tinglik vanem ainsaks rikke punktiks, ja tema lahkumine v\u00f5ib tuua kaasa monoliidi h\u00e4vimise. <\/p>\n

Seos<\/h3>\n

\nMonoliit esindab \u201esuur must kera\u201c (big ball of mud), mille muutmine v\u00f5ib tuua ettearvamatuid tagaj\u00e4rgi. Muute \u00fches kohas, v\u00f5ib kahjustada monoliiti teises kohas (just see \u201ek\u00f5rva s\u00fcgamine, *@ kukkus maha\u201c). See on seotud sellega, et monoliidi komponendid omavad v\u00e4ga keerulisi ja mis k\u00f5ige t\u00e4htsam, mitte selgeid seoseid.<\/p>\n

T\u00f5hustamine<\/h3>\n

\nMonoliidi t\u00f5hustamine on oma komponentide vaheliste keeruliste seoste t\u00f5ttu pikk protsess koos oma rituaaliga. Selline rituaal ei ole tavaliselt t\u00e4ielikult standardiseeritud ja seda edastatakse \"suust suhu\". <\/p>\n

Skaleeritavus<\/h3>\n

\nMonoliidi moodulitel v\u00f5ivad olla konfliktseid vajadusi ressursside osas, mist\u00f5ttu on vajalik leida kompromiss riistvara osas. Kujutage ette, et teie monoliit koosneb teenustest A ja B. Teenus A n\u00f5uab suurt k\u00f5vakettamahtu, samas kui teenus B n\u00f5uab palju m\u00e4lu. Sellisel juhul peab masin, kuhu monoliit paigaldatakse, toetama m\u00f5lema teenuse n\u00f5udmisi, v\u00f5i tuleb k\u00e4sitsi \u00fcks teenustest v\u00e4lja l\u00fclitada.<\/p>\n

Veel \u00fcks n\u00e4ide (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\u00e4isfunktsionaalset monoliiti v\u00f5i tuleb m\u00f5nes neist k\u00e4sitsi teenused B v\u00e4lja l\u00fclitada. <\/p>\n

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

\nKuna k\u00f5ik teenused on koos, siis kui monoliit eba\u00f5nnestub, eba\u00f5nnestuvad k\u00f5ik teenused korraga. Tegelikult pole see v\u00f5ib-olla nii halb, kuna jaotatud s\u00fcsteemis ei esine osalisi t\u00f5rkeid, kuid teisest k\u00fcljest v\u00f5ite kaotada k\u00f5ik oma s\u00fcsteemi kasutajad, sest t\u00f5rge funktsionaalsuses, mida kasutab 0,001% kasutajatest. <\/p>\n

Kangus<\/h3>\n

\nMonoliidi suuruse t\u00f5ttu on raske uutele tehnoloogiatele \u00fcle minna. Selle tulemusena tekkib eraldi \u00fclesanne hoida seda sama tingimuslikku seniori. Projekti alguses valitud tehnoloogiline pakett v\u00f5ib muutuda takistuseks toote arendamisel. <\/p>\n

Kokkuv\u00f5te<\/h2>\n

\nJ\u00e4rgmine kord r\u00e4\u00e4gime sellest, kuidas inimesed on p\u00fc\u00fcdnud neid probleeme lahendada, liikudes komponentide ja SOA suunas.<\/p>\n

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

\n

Loe edasi:<\/h4>\n

<\/p>\n