Sveiki, Habr. Šodien es turpinu publikāciju sēriju, ko rakstīju īpaši jaunas kursa plūsmas uzsākšanai. .
Ievads
Arhitektūras stila izvēle ir viens no fundamentālajiem tehniskajiem lēmumiem, veidojot informācijas sistēmu. Šajā rakstu sērijā es piedāvāju analizēt populārākos arhitektūras stilus būvniecības vajadzībām un atbildēt uz jautājumu, kad kurš arhitektūras stils ir vispiemērotākais. Prezentācijas procesā mēģināšu novilkt loģisku ķēdi, kas izskaidro arhitektūras stilu attīstību no monolītiem līdz mikropakalpojumiem.
В mēs tikām galā ar monolītu un nonācām pie secinājuma, ka monolītam ir vairākas problēmas: izmērs, savienojamība, izvietošana, mērogojamība, uzticamība un stingrība.
Šoreiz piedāvāju runāt par iespējām organizēt sistēmu kā moduļu/bibliotēku kopumu (komponentorientēta arhitektūra) vai servisu (service-oriented arhitektūra).
Uz komponentiem orientēta arhitektūra
Uz komponentiem orientēta arhitektūra ietver sistēmas izpildi kā komponentu kopu, ko var izmantot gan pašreizējos, gan turpmākajos projektos. Sadalot sistēmu komponentos, tiek ņemts vērā: to atkārtota izmantošana, to aizvietojamība, konteksta neatkarība, paplašināmība, iekapsulēšana un neatkarība.
Pareizi izmantojot komponentus, tiek atrisināta “lielās netīrumu bumbas” problēma (liels izmērs + augsta sakabe), un pašas sastāvdaļas var būt gan montāžas vienības (moduļi, bibliotēkas), gan izvietošanas vienības (pakalpojumi). Izvietošanas vienības ne vienmēr tiek piesaistītas darbības 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 komplekts. Šī pieeja nodrošina neatkarīgu attīstību, taču joprojām pastāv problēmas ar neatkarīgu mērogošanu un izvietošanu, kļūdu toleranci un neatkarību no kopējās tehnoloģiju kopas. Tāpēc modulis ir daļēji neatkarīgs komponents.
Lielākā problēma ar šādu monolītu ir tā, ka sadalīšana moduļos ir tīri loģiska un izstrādātāji to var viegli pārkāpt. Var parādīties galvenais modulis, kas pamazām pārvēršas par atkritumu izgāztuvi, var pieaugt atkarību grafiks starp moduļiem utt. Lai izvairītos no šādām problēmām, izstrāde jāveic vai nu ļoti nobriedušai komandai, vai arī “arhitekta” vadībā, kurš nodarbojas ar pilna laika koda pārskatīšanu un sit ar rokām izstrādātājiem, kuri pārkāpj loģisko struktūru.
“Ideālais” monolīts ir loģiski atdalītu moduļu kopums, no kuriem katrs aplūko savu datu bāzi.
Uz servisu orientēta arhitektūra
Ja sistēma ir jāorganizē pakalpojumu kopuma veidā, tad mēs runājam par uz pakalpojumiem orientētu arhitektūru. Tās principi ir uz lietotāju orientēta lietojumprogrammu sadarbspēja, biznesa pakalpojumu atkārtota izmantošana, tehnoloģiju steka neatkarība un autonomija (neatkarīga attīstība, mērogojamība un izvietošana).
Uz servisu orientēta arhitektūra (SOA = uz pakalpojumu orientēta arhitektūra) atrisina visas identificētās monolīta problēmas: notiekot izmaiņas, tiek ietekmēts tikai viens pakalpojums, un labi definēta API atbalsta labu komponentu iekapsulēšanu.
Bet ne viss ir tik gludi: SOA rada jaunas problēmas. Attālinātie zvani ir dārgāki nekā vietējie, un pienākumu pārdale starp komponentiem ir kļuvusi ievērojami dārgāka.
Starp citu, neatkarīgas izvietošanas iespēja ir ļoti svarīga pakalpojuma iezīme. Ja pakalpojumi ir jāizvieto kopā vai turklāt noteiktā secībā, tad sistēmu nevar uzskatīt par servisu orientētu. Šajā gadījumā viņi runā par izkliedētu monolītu (tiek uzskatīts par anti-modeli ne tikai no SOA, bet arī no mikropakalpojumu arhitektūras viedokļa).
Uz pakalpojumiem orientētu arhitektūru labi atbalsta arhitektu kopiena un pārdevēji. Tas nozīmē daudzu kursu un sertifikātu, labi izstrādātu modeļu klātbūtni. Pēdējais ietver, piemēram, labi zināmo uzņēmuma pakalpojumu kopni (ESB = enterprise service bus). Tajā pašā laikā ESB ir pārdevēju bagāža; tas nav obligāti jāizmanto SOA.
Uz pakalpojumiem orientētās arhitektūras popularitāte sasniedza maksimumu ap 2008. gadu, pēc tam tā sāka kristies, kas kļuva ievērojami dramatiskāka pēc mikropakalpojumu parādīšanās (~2015).
Secinājums
Pēc tam, kad esam pārrunājuši iespējas organizēt informācijas sistēmas servisu un moduļu veidā, ierosinu beidzot pāriet pie mikropakalpojumu arhitektūras principiem un nākamajā daļā īpašu uzmanību pievērst mikropakalpojumu arhitektūras atšķirībai no uz servisu orientētas arhitektūras.
Avots: www.habr.com