Izbira arhitekturnega sloga (2. del)

Pozdravljeni, Habr. Danes nadaljujem serijo publikacij, ki sem jih napisal posebej za začetek novega toka tečaja. "Arhitekt programske opreme".

Predstavitev

Izbira arhitekturnega stila je ena temeljnih tehničnih odločitev pri izgradnji informacijskega sistema. V tej seriji člankov predlagam, da analiziram najbolj priljubljene arhitekturne sloge za gradbene aplikacije in odgovorim na vprašanje, kdaj je kateri arhitekturni slog najprimernejši. V procesu predstavitve bom poskušal narisati logično verigo, ki pojasnjuje razvoj arhitekturnih slogov od monolitov do mikrostoritev.

В prejšnjič ukvarjali smo se z monolitom in prišli do zaključka, da ima monolit vrsto težav: velikost, povezljivost, uvedba, razširljivost, zanesljivost in togost.

Tokrat predlagam, da govorimo o možnostih organiziranja sistema kot nabora modulov/knjižnic (komponentno usmerjena arhitektura) ali storitev (storitveno usmerjena arhitektura).

Komponentno usmerjena arhitektura

Komponentno usmerjena arhitektura vključuje izvajanje sistema kot nabora komponent, ki jih je mogoče uporabiti v trenutnih in prihodnjih projektih. Pri razdelitvi sistema na komponente se upoštevajo: njihova ponovna uporabnost, njihova zamenljivost, neodvisnost od konteksta, razširljivost, enkapsulacija in neodvisnost.

S pravilno uporabo komponent je problem "velike žoge umazanije" (velika velikost + visoka spojka) rešen, same komponente pa so lahko tako montažne enote (moduli, knjižnice) kot enote za uvajanje (storitve). Razmestitvene enote niso vedno preslikane v tekoči proces: na primer, spletna aplikacija in baza podatkov sta razporejeni skupaj.

Najpogosteje so monoliti razviti kot sklop modulov. Ta pristop vodi k neodvisnemu razvoju, vendar težave neodvisnega prilagajanja in uvajanja, tolerance napak in neodvisnosti od celotnega tehnološkega sklada ostajajo. Zato je modul delno samostojna komponenta.

Največja težava takšnega monolita je, da je razdelitev na module čisto logična in jo lahko razvijalci zlahka porušijo. Lahko se pojavi osrednji modul, ki se postopoma spremeni v smetišče, lahko raste graf odvisnosti med moduli itd. Da bi se izognili takšnim težavam, mora razvoj izvajati zelo zrela ekipa ali pod vodstvom "arhitekta", ki se ukvarja s pregledom kode s polnim delovnim časom in bije roke razvijalcem, ki kršijo logično strukturo.

“Idealni” monolit je niz logično ločenih modulov, od katerih vsak gleda v svojo bazo podatkov.

Storitveno usmerjena arhitektura

Če naj bi bil sistem organiziran v obliki niza storitev, potem govorimo o storitveno orientirani arhitekturi. Njegova načela so na uporabnika osredotočena interoperabilnost aplikacij, ponovna uporaba poslovnih storitev, neodvisnost tehnološkega sklada in avtonomija (neodvisen razvoj, razširljivost in uvajanje).

Storitveno usmerjena arhitektura (SOA = service oriented architecture) rešuje vse ugotovljene težave monolita: sprememba vpliva le na eno storitev, dobro definiran API pa podpira dobro inkapsulacijo komponent.

Vendar ni vse tako gladko: SOA ustvarja nove težave. Oddaljeni klici so dražji od lokalnih, bistveno dražje pa je tudi prerazporejanje odgovornosti med komponentami.

Mimogrede, možnost neodvisne namestitve je zelo pomembna lastnost storitve. Če je treba storitve namestiti skupaj ali še več, v določenem zaporedju, potem sistema ni mogoče šteti za storitveno usmerjenega. V tem primeru govorijo o porazdeljenem monolitu (ki velja za anti-vzorec ne samo z vidika SOA, ampak tudi z vidika arhitekture mikrostoritev).

Storitveno usmerjeno arhitekturo dobro podpirajo arhitekturna skupnost in prodajalci. To pomeni prisotnost številnih tečajev in certifikatov, dobro razvitih vzorcev. Med slednje sodi na primer znano poslovno vodilo (ESB = enterprise service bus). Hkrati je ESB prtljaga prodajalcev, ni nujno, da se uporablja v SOA.

Priljubljenost storitveno usmerjene arhitekture je dosegla vrhunec okoli leta 2008, nato pa je začela upadati, kar je postalo bistveno bolj dramatično po pojavu mikrostoritev (~2015).

Zaključek

Ko smo razpravljali o možnostih organiziranja informacijskih sistemov v obliki storitev in modulov, predlagam, da končno preidemo na načela arhitekture mikrostoritev in v naslednjem delu posvetimo posebno pozornost razliki med arhitekturo mikrostoritev in storitveno usmerjeno arhitekturo.

Izbira arhitekturnega sloga (2. del)

Vir: www.habr.com

Dodaj komentar