Zdravo, Habr. Danas nastavljam niz publikacija koje sam napisao posebno za početak novog toka kursa. .
Uvod
Izbor arhitektonskog stila jedna je od temeljnih tehničkih odluka prilikom izgradnje informacionog sistema. U ovoj seriji članaka predlažem da analiziram najpopularnije arhitektonske stilove za građevinske aplikacije i odgovorim na pitanje kada je koji arhitektonski stil najpoželjniji. U procesu prezentacije pokušaću da nacrtam logički lanac koji objašnjava razvoj arhitektonskih stilova od monolita do mikroservisa.
В bavili smo se monolitom i došli smo do zaključka da monolit ima niz problema: veličina, povezanost, implementacija, skalabilnost, pouzdanost i krutost.
Ovaj put predlažem da govorimo o mogućnostima organizovanja sistema kao skupa modula/biblioteka (komponentno orijentisana arhitektura) ili servisa (uslužno orijentisana arhitektura).
Arhitektura orijentirana na komponente
Arhitektura orijentisana na komponente uključuje izvođenje sistema kao skupa komponenti koje se mogu koristiti iu tekućim i budućim projektima. Prilikom razlaganja sistema na komponente, uzimaju se u obzir: njihova ponovna upotreba, njihova zamjenjivost, nezavisnost od konteksta, proširivost, inkapsulacija i nezavisnost.
Pravilnom upotrebom komponenti rješava se problem „velike kugle prljavštine“ (velika veličina + visoka spojnica), a same komponente mogu predstavljati i montažne jedinice (moduli, biblioteke) i jedinice za implementaciju (servise). Jedinice za implementaciju nisu uvijek mapirane na tekući proces: na primjer, web aplikacija i baza podataka se postavljaju zajedno.
Najčešće se monoliti razvijaju kao skup modula. Ovaj pristup vodi nezavisnom razvoju, ali problemi nezavisnog skaliranja i implementacije, tolerancije grešaka i nezavisnosti od ukupnog tehnološkog steka ostaju. Zbog toga je modul djelomično nezavisna komponenta.
Najveći problem s takvim monolitom je što je podjela na module čisto logična i programeri je mogu lako prekršiti. Može se pojaviti modul jezgre, koji se postepeno pretvara u deponiju smeća, graf ovisnosti između modula može rasti i tako dalje. Da bi se izbjegli takvi problemi, razvoj bi trebao obavljati ili vrlo zreo tim, ili pod vodstvom „arhitekata“ koji se bavi stalnim pregledom koda i tuče programere koji krše logičku strukturu.
“Idealni” monolit je skup logički odvojenih modula, od kojih svaki gleda u svoju bazu podataka.
Servisno orijentisana arhitektura
Ako sistem treba da bude organizovan u vidu skupa usluga, onda govorimo o servisno orijentisanoj arhitekturi. Njegovi principi su interoperabilnost aplikacija usmjerena na korisnika, ponovna upotreba poslovnih usluga, neovisnost tehnološkog steka i autonomija (nezavisna evolucija, skalabilnost i implementacija).
Servisno orijentisana arhitektura (SOA = servisno orijentisana arhitektura) rešava sve identifikovane probleme monolita: samo jedna usluga je pogođena kada dođe do promene, a dobro definisan API podržava dobru inkapsulaciju komponenti.
Ali nije sve tako glatko: SOA stvara nove probleme. Daljinski pozivi su skuplji od lokalnih, a preraspodjela odgovornosti između komponenti je postala znatno skuplja.
Inače, mogućnost samostalnog postavljanja je vrlo važna karakteristika servisa. Ako se usluge moraju implementirati zajedno ili, štaviše, u određenom nizu, onda se sistem ne može smatrati servisno orijentiranim. U ovom slučaju, oni govore o distribuiranom monolitu (koji se smatra anti-uzorkom ne samo sa stanovišta SOA-e, već i sa stanovišta mikroservisne arhitekture).
Arhitektura orijentisana na usluge je dobro podržana od strane arhitektonske zajednice i dobavljača. To podrazumijeva prisustvo mnogih kurseva i certifikata, dobro razvijenih obrazaca. Ovo posljednje uključuje, na primjer, dobro poznatu uslužnu sabirnicu preduzeća (ESB = Enterprise service bus). U isto vrijeme, ESB je prtljag od dobavljača; ne mora se nužno koristiti u SOA-i.
Popularnost uslužno orijentisane arhitekture dostigla je vrhunac oko 2008. godine, nakon čega je počela da opada, što je postalo znatno dramatičnije nakon pojave mikroservisa (~2015).
zaključak
Nakon što smo razgovarali o mogućnostima organizovanja informacionih sistema u vidu servisa i modula, predlažem da konačno pređemo na principe mikroservisne arhitekture i da u narednom delu posebnu pažnju posvetimo razlici između mikroservisne arhitekture i uslužno orijentisane arhitekture.
izvor: www.habr.com