{"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\/sl\/blog\/administrirovanie\/vybor-arhitekturnogo-stilya-chast-1","title":{"rendered":"Izbira arhitekturnega sloga (del 1)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Pozdrav, Habr. Trenutno je u OTUS-u otvoren upis za novi ciklus kursa \u00abSoftware Architect\u00bb<\/a><\/noindex>. Uo\u010di po\u010detka kursa \u017eelim da podelim sa vama svoju autorsku \u010dlanak.<\/i><\/b><\/p>\n

<\/p>\n

Uvod<\/h2>\n

\nOdabir arhitektonskog stila jedan je od osnovnih tehni\u010dkih re\u0161enja pri izgradnji informacionog sistema. U ovoj seriji \u010dlanaka predla\u017eem da razmotrimo najpopularnije arhitektonske stilove izgradnje aplikacija i odgovorimo na pitanje kada je koji arhitektonski stil najprikladniji. Tokom izlaganja \u0107u poku\u0161ati da sprovedem logi\u010dki sled koji obja\u0161njava razvoj arhitektonskih stilova od monolita do mikroservisa.
\n<\/a><\/noindex><\/p>\n

Nekaj zgodovine<\/h2>\n

\nAko pitate programere: \u201eZa\u0161to su potrebni mikroservisi?\u201c, dobi\u0107ete veoma razli\u010dite odgovore. \u010cu\u0107ete da mikroservisi pobolj\u0161avaju skalabilnost, olak\u0161avaju razumevanje koda, pobolj\u0161avaju otpornost na gre\u0161ke, a ponekad \u0107ete \u010duti da omogu\u0107avaju \u201e\u010di\u0161\u0107enje koda\u201c. Hajde da se obratimo istoriji kako bismo shvatili koju su svrhu imali mikroservisi.<\/p>\n

Ukratko, mikroservisi su u na\u0161em trenutnom razumevanju nastali na slede\u0107i na\u010din: 2011. godine, D\u017eejms Ljuis, analiziraju\u0107i rad raznih kompanija, primetio je pojavu novog obrasca \u201emicro-app\u201c, koji je optimizovao SOA sa stanovi\u0161ta ubrzavanja implementacije servisa. Neko vreme kasnije, 2012. godine, na arhitektonskom samitu, obrazac je preimenovan u mikroservis. Tako je prvobitni cilj uvo\u0111enja mikroservisa bio pobolj\u0161anje poznatog time to market<\/b>.<\/p>\n

Na \u201etalasu hype-a\u201c, mikroservisi su bili 2015. godine. Prema nekim istra\u017eivanjima, nijedna konferencija nije prolazila bez izlaganja na temu mikroservisa. \u0160tavi\u0161e, neke konferencije su bile posve\u0107ene isklju\u010divo mikroservisima. Sada mnogi projekti po\u010dinju primenom ovog arhitektonskog stila, a ako projekt sadr\u017ei tonu legacy koda, verovatno se aktivno vr\u0161i migracija na mikroservise.<\/p>\n

I pored svega re\u010denog, jo\u0161 uvek je relativno mali broj programera koji mo\u017ee da defini\u0161e pojam \u201emikroservis\u201c. Ali o tome \u0107emo govoriti malo kasnije...<\/p>\n

Monolit<\/h2>\n

\nArhitekturni stil, ki se postavlja nasproti mikroservisnemu, je monolit (ali 'vse v enem'). O tem, kaj je monolit, verjetno ni smiselno govoriti, zato takoj na\u0161tejem pomanjkljivosti tega arhitekturnega sloga, ki so spro\u017eile nadaljnji razvoj arhitekturnih stilov: velikost, povezanost, uvajanje, skalabilnost, zanesljivost in rigidnost. Spodaj predlagam, da se seznanimo s posameznimi pomanjkljivostmi.<\/p>\n

Dimenzije<\/h3>\n

\nMonolit je zelo velik. In praviloma sodeluje z zelo velikimi bazami podatkov. Aplikacija postane tako obse\u017ena, da je ne more razumeti en sam razvijalec. Z monolitom lahko dobro delajo le tisti, ki so pre\u017eiveli dovolj \u010dasa s tem kodo, medtem ko novinci pogosto porabijo preve\u010d \u010dasa, da bi se posku\u0161ali razumeti z monolitom, in ni nujno, da jim bo uspelo. Obi\u010dajno pri delu z monolitom obstaja nek 'pogojski' senior, ki monolit pozna ve\u010d ali manj dobro in letos ali leto in pol omejuje druge nove razvijalce. Seveda je tak 'pogojski' senior edina to\u010dka odpovedi, in njegov odhod lahko privede do propada monolita. <\/p>\n

Povezanost<\/h3>\n

\nMonolit je 'velika kepica blata' (big ball of mud), spremembe v katerem lahko povzro\u010dijo nepredvidljive posledice. Ko spremeni\u0161 eno stvar, lahko po\u0161koduje\u0161 monolit na drugem mestu (tisto 'ugriznil si uho, *@ je odpadlo'). To je povezano z dejstvom, da imajo komponenti v monolitu zelo zapletene in, kar je najpomembneje, nejasne medsebojne odnose.<\/p>\n

Postavitev<\/h3>\n

\nUvajanje monolita je zaradi zapletenih medsebojnih odnosov med njegovimi komponentami dolgotrajen postopek z lastnim ritualom. Ta ritual obi\u010dajno ni dokon\u010dno standardiziran in se prena\u0161a 'iz ust v usta'. <\/p>\n

\u0160irljivost<\/h3>\n

\nModuli monolita imajo lahko nasprotujo\u010de si potrebe po virih, zaradi \u010desar je potrebno iskati kompromis z vidika strojne opreme. Predstavljajte si, da va\u0161 monolit sestoji iz storitev A in B. Storitev A je zahtevna glede velikosti trdega diska, medtem ko storitev B zahteva ve\u010djo koli\u010dino RAM-a. V tem primeru mora stroj, na katerega je name\u0161\u010den monolit, podpirati zahteve obeh storitev, ali pa bo treba ro\u010dno, umetno onemogo\u010diti eno od storitev.<\/p>\n

\u0160e en primer (bolj klasi\u010den): storitev A je veliko bolj priljubljena kot storitev B, zato \u017eelite, da je 100 storitev A in 10 storitev B. Spet sta na voljo dve mo\u017enosti: ali postavimo 100 polno funkcionalnih monolitov ali pa nekaterih od njih ro\u010dno izklopimo storitve B. <\/p>\n

Zanesljivost<\/h3>\n

\nKer so vse storitve skupaj, \u010de monolit pade, padejo vse storitve naenkrat. V resnici morda to ni tako slabo, vsaj delnih napak v distribuiranem sistemu ne bo, vendar pa lahko zaradi napake v funkcionalnosti, ki jo uporablja 0.001% uporabnikov, izgubite vse uporabnike va\u0161ega sistema. <\/p>\n

Odstotnost<\/h3>\n

\nZaradi velikosti monolita je te\u017eko preiti na nove tehnologije. Posledi\u010dno se kot posebna naloga izpostavi zadr\u017eevanje tistega prav posebnega seniorja. Izbrana tehnolo\u0161ka struktura na za\u010detku projekta lahko postane ovira, ki prepre\u010duje razvoj izdelka. <\/p>\n

Zaklju\u010dek<\/h2>\n

\nNaslednji\u010d bomo govorili o tem, kako so ljudje posku\u0161ali re\u0161iti omenjene te\u017eave s prehodom na komponente in SOA.<\/p>\n

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

\n

Preberi ve\u010d:<\/h4>\n

<\/p>\n