Pozdrav, Habr. Trenutno je u OTUS-u otvoren upis za novi ciklus kursa . Uoči početka kursa želim da podelim sa vama svoju autorsku članak.
Uvod
Odabir arhitektonskog stila jedan je od osnovnih tehničkih rešenja pri izgradnji informacionog sistema. U ovoj seriji članaka predlažem da razmotrimo najpopularnije arhitektonske stilove izgradnje aplikacija i odgovorimo na pitanje kada je koji arhitektonski stil najprikladniji. Tokom izlaganja ću pokušati da sprovedem logički sled koji objašnjava razvoj arhitektonskih stilova od monolita do mikroservisa.
Nekaj zgodovine
Ako pitate programere: „Zašto su potrebni mikroservisi?“, dobićete veoma različite odgovore. Čućete da mikroservisi poboljšavaju skalabilnost, olakšavaju razumevanje koda, poboljšavaju otpornost na greške, a ponekad ćete čuti da omogućavaju „čišćenje koda“. Hajde da se obratimo istoriji kako bismo shvatili koju su svrhu imali mikroservisi.
Ukratko, mikroservisi su u našem trenutnom razumevanju nastali na sledeći način: 2011. godine, Džejms Ljuis, analizirajući rad raznih kompanija, primetio je pojavu novog obrasca „micro-app“, koji je optimizovao SOA sa stanovišta ubrzavanja implementacije servisa. Neko vreme kasnije, 2012. godine, na arhitektonskom samitu, obrazac je preimenovan u mikroservis. Tako je prvobitni cilj uvođenja mikroservisa bio poboljšanje poznatog time to market.
Na „talasu hype-a“, mikroservisi su bili 2015. godine. Prema nekim istraživanjima, nijedna konferencija nije prolazila bez izlaganja na temu mikroservisa. Štaviše, neke konferencije su bile posvećene isključivo mikroservisima. Sada mnogi projekti počinju primenom ovog arhitektonskog stila, a ako projekt sadrži tonu legacy koda, verovatno se aktivno vrši migracija na mikroservise.
I pored svega rečenog, još uvek je relativno mali broj programera koji može da definiše pojam „mikroservis“. Ali o tome ćemo govoriti malo kasnije...
Monolit
Arhitekturni stil, ki se postavlja nasproti mikroservisnemu, je monolit (ali 'vse v enem'). O tem, kaj je monolit, verjetno ni smiselno govoriti, zato takoj naštejem pomanjkljivosti tega arhitekturnega sloga, ki so sprožile nadaljnji razvoj arhitekturnih stilov: velikost, povezanost, uvajanje, skalabilnost, zanesljivost in rigidnost. Spodaj predlagam, da se seznanimo s posameznimi pomanjkljivostmi.
Dimenzije
Monolit je zelo velik. In praviloma sodeluje z zelo velikimi bazami podatkov. Aplikacija postane tako obsežna, da je ne more razumeti en sam razvijalec. Z monolitom lahko dobro delajo le tisti, ki so preživeli dovolj časa s tem kodo, medtem ko novinci pogosto porabijo preveč časa, da bi se poskušali razumeti z monolitom, in ni nujno, da jim bo uspelo. Običajno pri delu z monolitom obstaja nek 'pogojski' senior, ki monolit pozna več ali manj dobro in letos ali leto in pol omejuje druge nove razvijalce. Seveda je tak 'pogojski' senior edina točka odpovedi, in njegov odhod lahko privede do propada monolita.
Povezanost
Monolit je 'velika kepica blata' (big ball of mud), spremembe v katerem lahko povzročijo nepredvidljive posledice. Ko spremeniš eno stvar, lahko poškoduješ 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.
Postavitev
Uvajanje monolita je zaradi zapletenih medsebojnih odnosov med njegovimi komponentami dolgotrajen postopek z lastnim ritualom. Ta ritual običajno ni dokončno standardiziran in se prenaša 'iz ust v usta'.
Širljivost
Moduli monolita imajo lahko nasprotujoče si potrebe po virih, zaradi česar je potrebno iskati kompromis z vidika strojne opreme. Predstavljajte si, da vaš monolit sestoji iz storitev A in B. Storitev A je zahtevna glede velikosti trdega diska, medtem ko storitev B zahteva večjo količino RAM-a. V tem primeru mora stroj, na katerega je nameščen monolit, podpirati zahteve obeh storitev, ali pa bo treba ročno, umetno onemogočiti eno od storitev.
Še en primer (bolj klasičen): storitev A je veliko bolj priljubljena kot storitev B, zato želite, da je 100 storitev A in 10 storitev B. Spet sta na voljo dve možnosti: ali postavimo 100 polno funkcionalnih monolitov ali pa nekaterih od njih ročno izklopimo storitve B.
Zanesljivost
Ker so vse storitve skupaj, če 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šega sistema.
Odstotnost
Zaradi velikosti monolita je težko preiti na nove tehnologije. Posledično pa se kot posebna naloga pojavi tudi zadrževanje tistega hipotetičnega seniorja. Izbrana tehnologija ob začetku projekta lahko postane ovira za razvoj produkta.
Zaključek
Naslednjič bomo govorili o tem, kako so ljudje poskušali rešiti omenjene težave s prehodom na komponente in SOA.
Preberi več:
Izvor: habr.com
