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

Sveiki, habr. Å obrÄ«d OTUS ir atvērta pieteikÅ”anās jaunai kursu straumei "ProgrammatÅ«ras arhitekts". Kursa sākuma priekÅ”vakarā es vēlos dalÄ«ties ar jums savā oriÄ£inālajā rakstā.

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.

Nedaudz vēstures

Mēģinot jautāt izstrādātājiem: ā€œKāpēc mums nepiecieÅ”ami mikropakalpojumi?ā€, jÅ«s saņemsiet dažādas atbildes. JÅ«s dzirdēsiet, ka mikropakalpojumi uzlabo mērogojamÄ«bu, padara kodu vieglāk saprotamu, uzlabo kļūdu toleranci, un dažreiz jÅ«s dzirdēsiet, ka tie ļauj "iztÄ«rÄ«t kodu". ApskatÄ«sim vēsturi, lai saprastu mikropakalpojumu raÅ”anās mērÄ·i.

ÄŖsi sakot, mikropakalpojumi mÅ«su paÅ”reizējā izpratnē radās Ŕādi: 2011. gadā Džeimss LÅ«iss, analizējot dažādu uzņēmumu darbu, vērsa uzmanÄ«bu uz jaunas ā€œmikrolietotnesā€ modeļa parādÄ«Å”anos, kas optimizēja SOA, lai paātrinātu pakalpojumus. Nedaudz vēlāk, 2012. gadā, arhitektÅ«ras samitā modelis tika pārdēvēts par mikropakalpojumu. Tādējādi sākotnējais mikropakalpojumu ievieÅ”anas mērÄ·is bija uzlabot bēdÄ«gi slaveno laiks tirgoties.

Mikropakalpojumi bija uz ažiotāžas viļņa 2015. gadā. Saskaņā ar dažiem pētÄ«jumiem neviena konference nebija pilnÄ«ga bez ziņojuma par mikropakalpojumu tēmu. Turklāt dažas konferences bija veltÄ«tas tikai mikropakalpojumiem. MÅ«sdienās daudzi projekti sāk izmantot Å”o arhitektÅ«ras stilu, un, ja projekts satur tonnas mantotā koda, tad, iespējams, tiek aktÄ«vi veikta migrācija uz mikropakalpojumiem.

Neskatoties uz visu iepriekÅ” minēto, diezgan neliels izstrādātāju skaits joprojām var definēt jēdzienu ā€œmikropakalpojumsā€. Bet par to parunāsim nedaudz vēlāk...

Monolīts

ArhitektÅ«ras stils, kas kontrastē ar mikropakalpojumiem, ir monolÄ«ts (vai viss vienā). Iespējams, nav jēgas stāstÄ«t, kas ir monolÄ«ts, tāpēc uzreiz uzskaitÄ«Å”u Ŕī arhitektÅ«ras stila trÅ«kumus, kas aizsāka arhitektÅ«ras stilu tālāku attÄ«stÄ«bu: izmēri, savienojamÄ«ba, izvietoÅ”ana, mērogojamÄ«ba, uzticamÄ«ba un stingrÄ«ba. Tālāk es ierosinu apskatÄ«t katru no trÅ«kumiem atseviŔķi.

Izmērs

MonolÄ«ts ir ļoti liels. Un tas parasti sazinās ar ļoti lielu datu bāzi. Lietojumprogramma kļūst pārāk liela, lai viens izstrādātājs to vispār saprastu. Ar monolÄ«tu var labi strādāt tikai tie, kuri ir pavadÄ«juÅ”i daudz laika, strādājot pie Ŕī koda, savukārt iesācēji pavadÄ«s daudz laika, mēģinot izdomāt monolÄ«tu, un nav garantijas, ka viņi to izdomās. Parasti, strādājot ar monolÄ«tu, vienmēr ir kāds ā€œnosacÄ«tsā€ seniors, kurÅ” vairāk vai mazāk labi pārzina monolÄ«tu un pusotra gada laikā sit pāri citiem jaunajiem izstrādātājiem. Protams, Ŕāds nosacÄ«ts vecākais ir viens neveiksmes punkts, un viņa aizieÅ”ana var izraisÄ«t monolÄ«ta nāvi.

Savienojamība

MonolÄ«ts ir ā€œliela dubļu bumbaā€, kuras izmaiņas var radÄ«t neparedzamas sekas. Veicot izmaiņas vienā vietā, var sabojāt monolÄ«tu citā (tas pats ā€œsaskrāpēji ausi, *@ nokritaā€). Tas ir saistÄ«ts ar faktu, ka monolÄ«ta komponentiem ir ļoti sarežģītas un, pats galvenais, nepārprotamas attiecÄ«bas.

IzvietoŔana

MonolÄ«ta izvietoÅ”ana tā sastāvdaļu sarežģīto attiecÄ«bu dēļ ir ilgs process ar savu rituālu. Šāds rituāls parasti nav pilnÄ«bā standartizēts un tiek nodots "mutiski".

Mērogojamība

MonolÄ«tajiem moduļiem var bÅ«t pretrunÄ«gas resursu vajadzÄ«bas, tādēļ ir nepiecieÅ”ams kompromiss attiecÄ«bā uz aparatÅ«ru. Iedomājieties, ka jums ir monolÄ«ts, kas sastāv no pakalpojumiem A un B. Pakalpojums A prasa cietā diska izmēru, bet pakalpojums B prasa RAM. Å ajā gadÄ«jumā vai nu maŔīnai, kurā ir uzstādÄ«ts monolÄ«ts, ir jāatbalsta abu pakalpojumu prasÄ«bas, vai arÄ« jums bÅ«s manuāli, mākslÄ«gi jāatspējo viens no pakalpojumiem.

Vēl viens piemērs (klasiskāks): pakalpojums A ir daudz populārāks nekā pakalpojums B, tāpēc vēlaties, lai bÅ«tu 100 pakalpojumi A un 10 pakalpojumi B. Atkal ir divas iespējas: vai nu mēs izvietojam 100 pilnvērtÄ«gus monolÄ«tus, vai arÄ« uz dažiem pēc tam. pakalpojumi B bÅ«s jāatspējo manuāli.

Uzticamība

Tā kā visi pakalpojumi atrodas kopā, ja monolīts krīt, tad visi pakalpojumi krīt uzreiz. Patiesībā tas var nebūt tik slikti, vismaz dalītā sistēmā nebūs daļēju kļūdu, bet, no otras puses, funkcionalitātes kļūdas dēļ, kuru izmanto 0.001% lietotāju, jūs varat zaudēt visus lietotājus. no jūsu sistēmas.

Inerce

MonolÄ«ta izmēra dēļ ir grÅ«ti pāriet uz jaunām tehnoloÄ£ijām. Rezultātā Ŕī ļoti nosacÄ«tā vecākā saglabāŔana Ŕķiet atseviŔķs uzdevums. Projekta sākumā izvēlētā tehnoloÄ£iju kaudze var kļūt par bloku, kas kavē produkta attÄ«stÄ«bu.

Secinājums

Nākamajā reizē mēs runāsim par to, kā cilvēki ir mēģinājuÅ”i atrisināt Ŕīs problēmas, pārejot uz komponentiem un SOA.

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

Lasīt vairāk:

Avots: www.habr.com

Pievieno komentāru