Arhitektūras stila izvēle (2. daļa)

Sveiki, Habr. Šodien turpināšu publikāciju sēriju, ko esmu izveidojis jaunā kursa uzsākšanai. «Programmatūras arhitekts».

Ievads

Arhitektūras stila izvēle ir viens no galvenajiem tehniskajiem lēmumiem informācijas sistēmas izveidē. Šajā rakstu sērijā es piedāvāju apskatīt populārākos lietojumprogrammu arhitektūras stilus un atbildēt uz jautājumu, kurā gadījumā kurš arhitektūras stils ir visvairāk vēlams. Izklāstot informāciju, es cenšos veidot loģisku secību, kas izskaidro arhitektūras stilu attīstību no monolītiem līdz mikroservisiem.

No iepriekšējā reizē Mēs esam izpētījuši monolītu un secinājuši, ka monolītam ir vairākas problēmas: izmērs, savstarpējā saistība, izvietošana, mērogojamība, uzticamība un cietība.

Šoreiz es piedāvāju runāt par iespēju organizēt sistēmu kā moduļu/bibliotēku kopumu (komponentu orientēta arhitektūra) vai pakalpojumu kopumu (pakalpojumu orientēta arhitektūra).

Komponentu orientēta arhitektūra

Komponentu orientēta arhitektūra paredz sistēmas izveidošanu kā kopumu komponentu, kurus var izmantot gan esošajos, gan nākotnes projektos. Sadalot sistēmu komponentos, tiek ņemti vērā: to piemērotība atkārtotai lietošanai, aizvietojamība, neatkarība no konteksta, paplašināmība, kapsulēšana un neatkarība.

Pareizi izmantojot komponentus, tiek atrisināta «lielā netīrības kamola» problēma (liels izmērs + augsta savstarpējā saistība), un paši komponenti var būt gan salikšanas vienības (moduļi, bibliotēkas), gan izvietojuma vienības (pakalpojumi). Izvietojuma vienības ne vienmēr atbilst izpildāmam procesam: piemēram, tīmekļa lietojumprogramma un datu bāze tiek izvietotas kopā.

Visbiežāk monolīti tiek izstrādāti kā moduļu kopums. Šāds pieejas veids nodrošina izstrādes neatkarību, taču paliek problēmas ar neatkarīgu mērogojamību un izvietošanu, kļūdu toleranci un atkarību no kopēja tehnoloģiju steka. Tieši tāpēc modulis ir daļēji neatkarīga komponente.

Galvenā problēma ar šādu monolītu ir tā, ka moduļu sadalījums ir pilnīgi loģisks un to viegli var izjaukt izstrādātāji. Var parādīties core modulis, kas pakāpeniski pārvēršas par atkritumu, var pieaugt atkarību grafiks starp moduļiem un tā tālāk. Lai izvairītos no šādām problēmām, izstrādei jānotiek vai nu ļoti pieredzējušai komandai, vai arī "arhitekta" uzraudzībā, kurš pilna laika veidā nodarbojas ar koda pārskatīšanu un soda tās izstrādātājus, kuri pārkāpj loģisko struktūru.

"Ideālais" monolīts ir loģiski sadalītu moduļu kopums, katrs no kuriem skatās uz savu datu bāzi.

Servisorientēta arhitektūra

Ja tomēr tiek plānota sistēmas organizācija kā pakalpojumu kopums, tad runa ir par servisorientētu arhitektūru. Tās principi: lietotājiem orientētu lietojumprogrammu savienojamība, biznesa pakalpojumu atkārtota izmantošana, neatkarība no tehnoloģiju klāsta un autonomija (neatkarīga attīstība, mērogojamība un izvietojamība).

Servisorientēta arhitektūra (SOA = service oriented architecture) atrisina visas monolīta norādītās problēmas: izmaiņu gadījumā tiek skarta tikai viena pakalpojums, un skaidri definēts API nodrošina labu komponentu inkapsulāciju.

Bet ne viss ir tik gludi: SOA rada jaunas problēmas. Attālinātie izsaukumi ir dārgāki nekā lokāli, un uzdevumu sadalīšana starp komponentiem ir ievērojami dārgāka.

Starpcitu, neatkarīgas izvietošanas iespēja ir ļoti svarīga pakalpojuma iezīme. Ja pakalpojumi jāizvieto kopā vai, vēl jo vairāk, noteiktā secībā, tad sistēma nevar tikt uzskatīta par servisorientētu. Šādā gadījumā runā par sadalītu monolītu (uzskata par antipatternu ne tikai no SOA viedokļa, bet arī mikroservisu arhitektūras kontekstā).

Servisorientēta arhitektūra ir labi atbalstīta arhitektūras kopienā un piegādātājos. No tā izriet liels kursu un sertifikāciju skaits, labi izstrādāti paraugi. Pēdējiem pieder, piemēram, labi zināmā uzņēmuma pakalpojumu autobuss (ESB = enterprise service bus). Tajā pašā laikā ESB ir piegādātāju bagāža, tā nav obligāti jāizmanto SOA.

Servisa orientēto arhitektūru vislielākajā mērā izmantoja ap 2008. gadu, pēc tam tās popularitāte sāka samazināties, un šis samazinājums kļuva krietni straujāks pēc mikroservisu parādīšanās (~2015. gads).

Secinājums

Pēc tam, kad apspriedām informācijas sistēmu organizēšanas iespējas, izmantojot pakalpojumus un moduļus, es piedāvāju beidzot pāriet pie mikroservisu arhitektūras principiem un pievērst īpašu uzmanību atšķirībām starp mikroservisu arhitektūru un servisa orientēto arhitektūru nākamajā daļā.

Avots: habr.com