Izbira arhitekturnega sloga (del 2)

Pozdravljen, Habr. Danes nadaljujem s serijo objav, ki sem jih napisal posebej ob začetku novega tečaja. «Software Architect».

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.

V prejšnjič Razjasnili smo monolit in ugotovili, da ima monolit vrsto težav: velikost, povezanost, uvajanje, razširljivost, zanesljivost in togost.

Tokrat predlagam, da se pogovorimo o možnostih organizacije sistema kot zbirke modulov/libotek (komponentno usmerjena arhitektura) ali storitev (storitev usmerjena arhitektura).

Komponentno usmerjena arhitektura

Komponentno usmerjena arhitektura predvideva izvedbo sistema kot zbirko komponent, ki se jih lahko uporablja tako v trenutnih kot tudi v prihodnjih projektih. Pri razdelitvi sistema na komponente se upoštevajo: primernost za ponovno uporabo, zamenljivost, neodvisnost od konteksta, razširljivost, kapsulacija in neodvisnost.

Ob pravilni uporabi komponent se reši problem "velike gmote umazanije" (velika velikost + visoka povezanost), same komponente pa lahko predstavljajo tako enote zbiranja (moduli, knjižnice), kot tudi enote uvajanja (storitve). Enote uvajanja ne prikazujejo vedno izpolnjenega procesa: na primer, spletna aplikacija in baza podatkov se uvajata skupaj.

Najpogosteje se monoliti razvijajo kot zbirka modulov. Tak pristop zagotavlja neodvisnost razvoja, vendar pa težave neodvisnega razširjanja in uvajanja, odpornosti na napake in neodvisnosti od skupnega tehnološkega sklada ostajajo. Zato je modul - delno neodvisna komponenta.

Največja težava takšnega monolita pa je v tem, da je delitev na module čisto logična in jo lahko enostavno kršijo razvijalci. Lahko se pojavi modul core, ki postopoma postane smetišče, lahko se povečuje graf odvisnosti med moduli in tako dalje. Da bi se izognili takšnim težavam, mora razvoj potekati bodisi z zelo zrelo ekipo bodisi pod vodstvom 'arhitekta', ki se ves čas ukvarja z revizijo kode in strogo opominja razvijalce, ki kršijo logično strukturo.

"Idealni" monolit predstavlja zbirko logično ločenih modulov, vsak od njih pa ima svojo bazo podatkov.

Storitev usmerjena arhitektura

Če se načrtuje organizacija sistema v obliki niza storitev, govorimo o arhitekturi, usmerjeni v storitve. Njeni principi so: združljivost aplikacij, usmerjenih na uporabnike, večkratna uporaba poslovnih storitev, neodvisnost od nabora tehnologij in avtonomija (neodvisna evolucija, skalabilnost in izvajanje).

Arhitektura, usmerjena v storitve (SOA = service oriented architecture), rešuje vse zgoraj navedene probleme monolita: pri spremembi je prizadeta le ena storitev, medtem ko jasno opredeljeno API ohranja dobro enkapsulacijo komponent.

Vendar pa ni vse tako preprosto: SOA povzroča nove probleme. Oddaljeni klici so dražji od lokalnih, razporeditev nalog med komponentami pa je postala znatno dražja.

Mimogrede, možnost neodvisnega izvajanja je zelo pomembna značilnost storitve. Če se storitve morajo izvajati skupaj ali, še huje, v določenem zaporedju, sistem ne more biti obravnavan kot usmerjen v storitve. V tem primeru govorimo o distribuiranem monolitu (kar se šteje za antipaternem ne le z vidika SOA, temveč tudi mikrostoritvene arhitekture).

Arhitektura, usmerjena v storitve, je dobro podprta s strani arhitekturne skupnosti in prodajalcev. Iz tega sledi, da je na voljo veliko tečajev in certifikatov ter dobro razdelanih vzorcev. Med slednjimi se nahaja tudi znana podjetniška storitvena vodila (ESB = enterprise service bus). Hkrati je ESB breme prodajalcev, ki se ne sme nujno uporabljati v SOA.

Vrhunec priljubljenosti arhitekture, usmerjene v storitve, je bil okoli leta 2008, nato pa je začela upadati, kar je postalo bistveno bolj dramatično po pojavu mikrostoritev (~2015).

Zaključek

Potem ko smo razpravljali o možnostih organizacije informacijskih sistemov v obliki storitev in modulov, predlagam, da se končno osredotočimo na principe mikrostoritvene arhitekture in posebno pozornost namenimo razlikam med mikrostoritveno arhitekturo in arhitekturo, usmerjeno v storitve, v naslednjem delu.

Izvor: habr.com