Að velja byggingarstíl (hluti 1)

Halló, habr. Skráning í nýtt námskeiðsstraum er opið núna hjá OTUS "hugbúnaðararkitekt". Í aðdraganda námskeiðsins vil ég deila með ykkur upprunalegu greininni minni.

Inngangur

Val á byggingarstíl er ein af grundvallar tæknilegum ákvörðunum við smíði upplýsingakerfis. Í þessari greinaröð legg ég til að greina vinsælustu byggingarstíla fyrir byggingarforrit og svara spurningunni um hvenær hvaða byggingarstíll er æskilegastur. Í kynningarferlinu mun ég reyna að teikna rökrétta keðju sem útskýrir þróun byggingarstíla frá einlitum til örþjónustu.

Smá saga

Ef þú reynir að spyrja forritara: „Af hverju þurfum við örþjónustur?“ færðu margvísleg svör. Þú munt heyra að örþjónustur bæta sveigjanleika, gera kóða auðveldari að skilja, bæta bilanaþol og stundum muntu heyra að þær leyfa þér að "hreinsa til kóðann þinn." Við skulum skoða söguna til að skilja tilganginn á bak við tilkomu örþjónustu.

Í stuttu máli urðu örþjónustur í núverandi skilningi okkar sem hér segir: Árið 2011 vakti James Lewis, við að greina vinnu ýmissa fyrirtækja, athygli á tilkomu nýs „örappa“ mynsturs, sem fínstillti SOA hvað varðar hraða dreifingu á þjónusta. Nokkru síðar, árið 2012, á leiðtogafundi um arkitektúr, var mynstrið breytt í örþjónustu. Þannig var upphaflega markmiðið með því að kynna örþjónustu að bæta hið alræmda tími til markaðarins.

Örþjónustur voru á efla bylgjunni árið 2015. Samkvæmt sumum rannsóknum var ekki ein einasta ráðstefna lokið án skýrslu um efnið örþjónustur. Þar að auki voru sumar ráðstefnur eingöngu helgaðar örþjónustu. Nú á dögum byrja mörg verkefni að nota þennan byggingarstíl, og ef verkefnið inniheldur tonn af eldri kóða, þá er flutningur yfir í örþjónustu líklega virkur í gangi.

Þrátt fyrir allt ofangreint getur tiltölulega lítill fjöldi forritara samt skilgreint hugtakið „örþjónusta“. En við ræðum þetta aðeins seinna...

Monolith

Byggingarstíllinn sem stangast á við örþjónustu er einhliða (eða allt í einu). Það er sennilega ekki skynsamlegt að segja til um hvað monolith er, svo ég mun strax telja upp ókosti þessa byggingarstíls, sem kom af stað frekari þróun byggingarstíla: stærð, tengsl, dreifing, sveigjanleiki, áreiðanleiki og stífni. Hér að neðan legg ég til að litið verði á hvern galla fyrir sig.

Stærð

Einlitinn er mjög stór. Og það hefur venjulega samskipti við mjög stóran gagnagrunn. Forritið verður of stórt til að einn verktaki geti yfirhöfuð skilið það. Aðeins þeir sem hafa eytt miklum tíma í að vinna í þessum kóða geta unnið vel með einlitinn, á meðan byrjendur munu eyða miklum tíma í að reyna að finna út einlitinn og það er engin trygging fyrir því að þeir komist að því. Venjulega, þegar unnið er með einliða, er alltaf einhver „skilyrtur“ eldri sem þekkir einliðann meira eða minna vel og slær hendurnar á aðra nýja þróunaraðila innan eins og hálfs árs. Eðlilega er slíkur skilyrtur eldri eintakur bilunarpunktur og brotthvarf hans getur leitt til dauða einliða.

Tengsl

Einlitinn er „stór drullukúla“, breytingar sem geta leitt til ófyrirsjáanlegra afleiðinga. Með því að gera breytingar á einum stað geturðu skemmt monolith á öðrum (sama "þú klóraðir þér í eyrað, *@ datt af"). Þetta er vegna þess að íhlutirnir í monolith hafa mjög flókin og, síðast en ekki síst, óljós tengsl.

Dreifing

Að dreifa einlita, vegna flókinna tengsla milli íhluta hans, er langt ferli með eigin helgisiði. Slík helgisiði er venjulega ekki fullkomlega staðlað og er miðlað „munnlega“.

Stærð

Monolith einingar geta haft misvísandi auðlindaþarfir, sem krefst málamiðlunar hvað varðar vélbúnað. Ímyndaðu þér að þú sért með einliða sem samanstendur af þjónustu A og B. Þjónusta A er krefjandi á stærð harða disksins og þjónusta B krefst vinnsluminni. Í þessu tilviki verður annaðhvort vélin sem monolith er sett upp á að styðja kröfur beggja þjónustunnar, eða þú verður að slökkva handvirkt á einni af þjónustunum.

Annað dæmi (klassískara): þjónusta A er miklu vinsælli en þjónusta B, þannig að þú vilt að það séu 100 þjónusta A og 10 þjónusta B. Aftur, tveir valkostir: annaðhvort sendum við 100 fullgilda einliða, eða á suma þá Slökkva verður á þjónustu B handvirkt.

Áreiðanleiki

Þar sem allar þjónustur eru staðsettar saman, ef einingin fellur, þá falla allar þjónustur í einu. Reyndar er þetta kannski ekki svo slæmt, að minnsta kosti verða engar hlutabilanir í dreifðu kerfi, en á hinn bóginn, vegna galla í virkni sem er notuð af 0.001% notenda, geturðu misst alla notendur kerfisins þíns.

Tregðu

Vegna stærðar einlitsins er erfitt að skipta yfir í nýja tækni. Þar af leiðandi er það sérstakt verkefni að halda sama eldri. Tæknistaflan sem valin er í upphafi verkefnis getur orðið blokk sem hindrar þróun vörunnar.

Ályktun

Næst munum við tala um hvernig fólk hefur reynt að leysa þessi vandamál með því að fara yfir í íhluti og SOA.

Að velja byggingarstíl (hluti 1)

Lestu meira:

Heimild: www.habr.com

Bæta við athugasemd