Pozdrav, Habr. Danas nastavljam niz publikacija koje sam napisao posebno za početak novog toka tečaja. .
Uvod
Odabir arhitektonskog stila jedna je od temeljnih tehničkih odluka pri izgradnji informacijskog sustava. U ovoj seriji članaka predlažem analizu najpopularnijih arhitektonskih stilova za primjenu u građevinarstvu i odgovor na pitanje kada je koji arhitektonski stil najpoželjniji. U procesu izlaganja pokušat ću povući logičan lanac koji objašnjava razvoj arhitektonskih stilova od monolita do mikroservisa.
В bavili smo se monolitom i došli do zaključka da monolit ima niz problema: veličina, povezivost, implementacija, skalabilnost, pouzdanost i krutost.
Ovaj put predlažem da govorimo o mogućnostima organiziranja sustava kao skupa modula/biblioteka (arhitektura orijentirana na komponente) ili usluga (arhitektura orijentirana na usluge).
Komponentno orijentirana arhitektura
Komponentno orijentirana arhitektura uključuje izvođenje sustava kao skupa komponenti koje se mogu koristiti u trenutnim i budućim projektima. Kada se sustav rastavlja na komponente, u obzir se uzimaju: njihova ponovna upotreba, njihova zamjenjivost, neovisnost o kontekstu, proširivost, kapsulacija i neovisnost.
Pravilnom upotrebom komponenti rješava se problem “velike kugle prljavštine” (velika veličina + visoka sprega), a same komponente mogu predstavljati i montažne jedinice (moduli, biblioteke) i jedinice za postavljanje (servisi). Jedinice za implementaciju nisu uvijek preslikane na proces koji se izvodi: na primjer, web aplikacija i baza podataka su implementirane zajedno.
Najčešće se monoliti razvijaju kao skup modula. Ovaj pristup vodi neovisnom razvoju, ali ostaju problemi neovisnog skaliranja i postavljanja, tolerancije na greške i neovisnosti o cjelokupnom tehnološkom nizu. Zato je modul djelomično neovisna komponenta.
Najveći problem s takvim monolitom je što je podjela na module čisto logična i programeri je lako mogu prekršiti. Može se pojaviti osnovni modul koji se postupno pretvara u deponij smeća, može rasti graf ovisnosti između modula i tako dalje. Da bi se izbjegli takvi problemi, razvoj bi trebao provoditi ili vrlo zreo tim ili pod vodstvom "arhitekta" koji je uključen u pregled koda s punim radnim vremenom 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 orijentirana arhitektura
Ako bi sustav trebao biti organiziran u obliku skupa usluga, tada govorimo o servisno orijentiranoj arhitekturi. Njegovi principi su interoperabilnost aplikacija usmjerena na korisnika, ponovna upotreba poslovnih usluga, neovisnost o tehnološkom nizu i autonomija (neovisna evolucija, skalabilnost i implementacija).
Servisno orijentirana arhitektura (SOA = service oriented architecture) rješava sve identificirane probleme monolita: promjena utječe na samo jednu uslugu, a dobro definiran API podržava dobru enkapsulaciju komponenti.
Ali nije sve tako glatko: SOA stvara nove probleme. Daljinski pozivi skuplji su od lokalnih, a preraspodjela odgovornosti među komponentama postala je znatno skuplja.
Usput, mogućnost samostalnog postavljanja vrlo je važna značajka usluge. Ako se usluge moraju implementirati zajedno ili, štoviše, u određenom slijedu, tada se sustav ne može smatrati servisno orijentiranim. U ovom slučaju, oni govore o distribuiranom monolitu (koji se smatra anti-uzorkom ne samo sa stajališta SOA-e, već i sa gledišta arhitekture mikroservisa).
Arhitektura orijentirana na usluge dobro je podržana od strane arhitektonske zajednice i dobavljača. To podrazumijeva prisutnost mnogih tečajeva i certifikata, dobro razvijenih obrazaca. Potonji uključuje, na primjer, dobro poznatu sabirnicu poslovnih usluga (ESB = enterprise service bus). U isto vrijeme, ESB je prtljaga dobavljača; ne mora se nužno koristiti u SOA-i.
Popularnost uslužno orijentirane arhitekture dosegla je vrhunac oko 2008. godine, nakon čega je počela padati, što je postalo znatno dramatičnije nakon pojave mikroservisa (~2015.).
Zaključak
Nakon što smo razgovarali o mogućnostima organiziranja informacijskih sustava u obliku servisa i modula, predlažem da konačno prijeđemo na principe mikroservisne arhitekture iu sljedećem dijelu posebnu pozornost posvetimo razlici između mikroservisne arhitekture i servisno orijentirane arhitekture.
Izvor: www.habr.com