Odabir arhitektonskog stila (dio 2)

Pozdrav, Habr. Danas nastavljam seriju objava koju sam napisao posebno za početak novog toka tečaja «Softverski arhitekt».

Uvod

Odabir arhitektonskog stila predstavlja jedno od temeljnih tehničkih rješenja prilikom izgradnje informacijskog sustava. U ovoj seriji članaka predlažem da proučimo najpopularnije arhitektonske stilove izgradnje aplikacija i odgovorimo na pitanje kada je koji arhitektonski stil najpoželjniji. Tijekom izlaganja pokušat ću izvesti logički slijed koji objašnjava razvoj arhitektonskih stilova od monolita do mikroservisa.

U prošli put Razjasnili smo monolit i došli do zaključka da monolit ima niz problema: veličinu, povezanost, implementaciju, skalabilnost, pouzdanost i krutost.

Ovaj put predlažem da razgovaramo o mogućnostima organizacije sustava u obliku skupa modula/biblioteka (arhitektura orijentirana na komponente) ili usluga (arhitektura orijentirana na servise).

Arhitektura orijentirana na komponente

Arhitektura orijentirana na komponente podrazumijeva izvođenje sustava u obliku skupa komponenti koje se mogu koristiti kako u trenutnim, tako i u budućim projektima. Prilikom razbijanja sustava na komponente uzimaju se u obzir: pogodnost za ponovnu upotrebu, zamjenjivost, neovisnost o kontekstu, proširivost, inkapsulacija i neovisnost.

Kada se komponente pravilno koriste, rješava se problem "velikog klupka blata" (velika veličina + visoka povezanost), a same komponente mogu predstavljati kao jedinice sastavljanja (moduli, biblioteke), tako i jedinice implementacije (usluge). Jedinice implementacije ne odražavaju uvijek izvršni proces: na primjer, web aplikacija i baza podataka se implementiraju zajednički.

Najčešće se monoliti razvijaju u obliku skupa modula. Ovaj pristup osigurava neovisnost razvoja, no problemi neovisnog skaliranja i implementacije, otpornosti na greške i neovisnosti od zajedničkog tehnološkog stoga ostaju. Iz tog razloga modul predstavlja djelomično neovisnu komponentu.

Najveći problem takvog monolita je u tome što je razdvajanje na module isključivo logičko i može ga lako narušiti programeri. Može nastati core modul koji se postupno pretvara u smeće, može rasti graf zavisnosti među modulima i slično. Da bi se izbegli takvi problemi, razvoj bi trebao voditi ili veoma zreo tim, ili pod vođstvom "arhitekta" koji se u potpunosti posvećuje code review-u i kažnjava programere koji krše logičku strukturu.

„Idealni“ monolit sastoji se od skupa logički odvojenih modula, od kojih svaki pristupa svojoj bazi podataka.

Arhitektura orijentisana na servise

Ako se planira organizacija sistema kao skup servisa, tada govorimo o arhitekturi orijentisanoj na servise. Njeni principi su: kombinabilnost aplikacija orijentisanih na korisnike, višekratna upotreba poslovnih servisa, nezavisnost od skupa tehnologija i autonomija (neovisna evolucija, skalabilnost i implementacija).

Arhitektura orijentisana na servise (SOA = service oriented architecture) rešava sve navedene probleme monolita: promena utiče samo na jednu uslugu, a jasno definisan API podržava dobru inkapsulaciju komponenata.

Međutim, nije sve tako jednostavno: SOA dovodi do stvaranja novih problema. Daljski pozivi su skuplji od lokalnih, a preraspodela obaveza među komponentama postala je znatno skuplja.

Usput, mogućnost nezavisne implementacije je veoma važna karakteristika servisa. Ako se servisi moraju implementirati zajedno ili, još gore, u određenom redosledu, sistem se ne može smatrati orijentisanim na servise. U takvim slučajevima govorimo o distribuiranom monolitu (koji se smatra antipaternom ne samo iz perspektive SOA, već i mikroservisne arhitekture).

Arhitektura orijentisana na servise dobro je podržana od strane arhitektonske zajednice i dobavljača. Odatle proizlazi postojanje mnogih kurseva i sertifikacija, kao i dobro razvijenih obrazaca. Među njima je, na primer, poznati servisni autobus preduzeća (ESB = enterprise service bus). Pri tome, ESB je teret dobavljača, ne mora se nužno koristiti u SOA.

Vrhunac popularnosti arhitekture usmjerenih na usluge bio je oko 2008. godine, nakon čega je uslijedio pad, koji je postao znatno oštriji nakon pojave mikroservisa (~2015. godine).

Zaključak

Nakon što smo razgovarali o mogućnostima organizacije informacijskih sustava u obliku usluga i modula, predlažem da pređemo na principe mikroservisne arhitekture i obratimo posebnu pozornost na razliku između mikroservisne arhitekture i arhitekture usmjerenih na usluge u sljedećem dijelu.

Izvor: habr.com