{"id":80035,"date":"2020-05-02T13:42:54","date_gmt":"2020-05-02T11:42:54","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/udobnye-arhitekturnye-patterny"},"modified":"2020-05-02T13:42:54","modified_gmt":"2020-05-02T11:42:54","slug":"udobnye-arhitekturnye-patterny","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/udobnye-arhitekturnye-patterny","title":{"rendered":"Mugavad arhitektuurilised mustrid","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Tere, Habr!<\/p>\n

<\/p>\n

Seoses praeguste s\u00fcndmustega koroonaviiruse t\u00f5ttu on mitmed internetiteenused hakanud saama suuremat koormust. N\u00e4iteks, \u00fcks jaekettest Suurbritannias lihtsalt sulges oma veebisaidi tellimuste jaoks<\/a><\/noindex>, kuna ressursid said otsa. Ja kaugel sellest, et serverit saaks lihtsalt kiiremaks muuta, lisades v\u00f5imsamat varustust, peab klientide p\u00e4ringud siiski t\u00f6\u00f6tlema (v\u00f5i nad l\u00e4hevad konkurentide juurde).<\/p>\n

<\/p>\n

Selles artiklis r\u00e4\u00e4gin l\u00fchidalt populaarsetest praktikatest, mis v\u00f5imaldavad luua kiire ja t\u00f5rkeennetuse teenuse. Kuid valitud arendusmoodulite seas on ainult need, millega praegu on lihtne \u00e4ra kasutada<\/strong>. Iga punkti jaoks on teil kas juba olemasolevad teegid v\u00f5i v\u00f5imalus probleem lahendada pilveteenuse abil.<\/p>\n

<\/a><\/noindex><\/p>\n

Horiontaalne skaleerimine<\/h1>\n

<\/p>\n

K\u00f5ige lihtsam ja k\u00f5igile tuntud punkt. \u00dcldiselt on k\u00f5ige sagedamini kaks koormuse jaotamise skeemi \u2014 horisontaalne ja vertikaalne skaleerimine. Esimesel juhul<\/a><\/noindex> lubate teenustel t\u00f6\u00f6tada paralleelselt, jaotades seel\u00e4bi koormuse nende vahel. Teisel<\/a><\/noindex> te tellite v\u00f5imsamaid servereid v\u00f5i optimeerite koodi.<\/p>\n

<\/p>\n

N\u00e4iteks v\u00f5tan abstraktse pilveteenuse failide salvestamiseks, sarnase OwnCloudile, OneDrive'ile ja muudele.<\/p>\n

<\/p>\n

Allpool on standardne diagramm sarnase s\u00fcsteemi kohta, kuid see demonstreerib vaid s\u00fcsteemi keerukust. Peame leidma viisi teenuste s\u00fcnkroonimiseks. Mis juhtub, kui kasutaja salvestab faili tahvelarvutisse ja soovib seda hiljem vaadata telefonist?<\/p>\n

<\/p>\n

\"Mugavad
\nErinevus l\u00e4henemistes: vertikaalsel skaleerimisel oleme valmis suurendama s\u00f5lmede v\u00f5imsust, samas kui horisontaalsel lisame uusi s\u00f5lmi, et koormust jaotada.<\/p>\n

<\/p>\n

CQRS<\/h1>\n

<\/p>\n

Command Query Responsibility Segregation<\/a><\/noindex> on \u00fcsna oluline muster, kuna see v\u00f5imaldab erinevatel klientidel mitte ainult \u00fchenduda erinevate teenustega, vaid ka saada samu s\u00fcndmuste vooge. Selle eelised ei ole lihtsa rakenduse puhul nii ilmsed, kuid see on \u00e4\u00e4rmiselt oluline (ja lihtne) koormatud teenuse jaoks. Selle tuum: sisenevad ja v\u00e4ljuvad andmevood ei tohiks \u00fcksteist ristuda. See t\u00e4hendab, et te ei saa saata p\u00e4ringut ja oodata vastust, vaid saadate p\u00e4ringu teenusesse A, kuid saate vastuse teenuses B.<\/p>\n

<\/p>\n

Selle l\u00e4henemise esimene eelis on v\u00f5imalus katkestada \u00fchendus (selle s\u00f5na laiemas t\u00e4henduses) pika k\u00fcsimise protsessi k\u00e4igus. Toome n\u00e4iteks enam-v\u00e4hem tavalise j\u00e4rjestuse:<\/p>\n

<\/p>\n

    \n
  1. Klient saatis palveli serverile.<\/li>\n
  2. Server alustas pika t\u00f6\u00f6tlemisega.<\/li>\n
  3. Server vastas kliendile tulemusega.<\/li>\n<\/ol>\n

    <\/p>\n

    Kujutage ette, et punktis 2 toimus \u00fchenduse katkestamine (kas v\u00f5rgu uuendamine v\u00f5i kasutaja liikus teisele lehele, katkestades \u00fchenduse). Sel juhul on serveril keeruline saata vastust kasutajale, milline teave on k\u00e4ideldud. CQRS-i rakendades on j\u00e4rjestus pisut erinev:<\/p>\n

    <\/p>\n

      \n
    1. Klient tellis v\u00e4rskendusi.<\/li>\n
    2. Klient saatis palveli serverile.<\/li>\n
    3. Server vastas 'p\u00e4ring vastu v\u00f5etud'.<\/li>\n
    4. Server vastas tulemusega kanali kaudu punktist '1'.<\/li>\n<\/ol>\n

      <\/p>\n

      \"Mugavad<\/p>\n

      <\/p>\n

      Nagu n\u00e4ha, on skeem pisut keerukam. Veelgi enam, intuitiivne request-response l\u00e4henemine ei ole siin kohal. K\u00fcll aga on selge, et \u00fchenduse katkestamine p\u00e4ringu t\u00f6\u00f6tlemise k\u00e4igus ei too kaasa viga. Veelgi enam, kui kasutaja on tegelikult \u00fchendatud teenusega mitme seadme kaudu (n\u00e4iteks mobiiltelefoni ja tahvelarvuti kaudu), saab korraldada nii, et vastus j\u00f5uaks m\u00f5lemasse seadmesse.<\/p>\n

      <\/p>\n

      Huvitav on see, et sissetulevate s\u00f5numite t\u00f6\u00f6tlemise kood on \u00fchesugune (mitte 100%) nii klientide poolt m\u00f5jutatud s\u00fcndmuste kui ka teiste s\u00fcndmuste jaoks, sealhulgas teiste klientide s\u00fcndmuste jaoks.<\/p>\n

      <\/p>\n

      Kuid tegelikkuses saame me lisaboonuseid seet\u00f5ttu, et \u00fchesuunalist voogu saab t\u00f6\u00f6delda funktsionaalses stiilis (kasutades RX ja analooge). Ja see on juba t\u00f5sine pluss, kuna p\u00f5him\u00f5tteliselt saab rakenduse teha t\u00e4iesti reaktiivseks, rakendades samas funktsionaalset l\u00e4henemist. Suurtele programmidele v\u00f5ib see m\u00e4rkimisv\u00e4\u00e4rselt s\u00e4\u00e4sta ressursse arendamisel ja hooldamisel.<\/p>\n

      <\/p>\n

      Kui kombineerida see l\u00e4henemine horisontaalse skaleerimisega, siis saadame me soovi korral p\u00e4ringud \u00fchele serverile ja saame vastused teisest. Seega saab klient ise valida endale sobiva teenuse, samas kui s\u00fcsteem suudab sisemiselt s\u00fcndmusi \u00f5igesti t\u00f6\u00f6delda.<\/p>\n

      <\/p>\n

      Event Sourcing<\/h1>\n

      <\/p>\n

      Nagu teate, on jaotatud s\u00fcsteemi \u00fcheks peamiseks omaduseks \u00fcldise aja ja \u00fchise kriitilise sektsiooni puudumine. \u00dche protsessi raames v\u00f5ite synchroniseerida (k\u00f5igi samade mutex'ite abil), mille jooksul olete kindel, et keegi teine ei t\u00e4ida seda koodi. Kuid jaotatud s\u00fcsteemi puhul on see ohtlik, kuna see toob kaasa kulutusi ning tapab kogu skaleeritavuse v\u00f5lu \u2014 k\u00f5ik komponendid peavad ikkagi ootama \u00fcksteist.<\/p>\n

      <\/p>\n

      Seet\u00f5ttu saame olulise t\u00f5e \u2014 kiiret jaotatud s\u00fcsteemi ei saa synchroniseerida, kuna muidu v\u00e4hendame j\u00f5udlust. Teiselt poolt vajame sageli teatud komponentide j\u00e4rjepidevust. Selleks saab kasutada l\u00e4henemist eventual consistency<\/a><\/noindex>, kus garanteeritakse, et andmete muutuste puudumisel teatud ajavahemiku jooksul p\u00e4rast viimast uuendust (\u201el\u00f5puks\u201d) tagastavad k\u00f5ik p\u00e4ringud viimane uuendatud v\u00e4\u00e4rtus.<\/p>\n

      <\/p>\n

      Oluline on m\u00f5ista, et traditsiooniliste andmebaaside puhul rakendatakse sageli ranget j\u00e4rjepidevust<\/a><\/noindex>, kus iga s\u00f5lm omab samu andmeid (sarnast saavutatakse sageli siis, kui tehingut peetakse kehtivaks alles p\u00e4rast teise serveri vastust). Siiski on siin m\u00f5ned leevendused isoleerimise tasetest, kuid p\u00f5hikirjeldus j\u00e4\u00e4b samaks \u2014 te saate elada t\u00e4iesti koosk\u00f5lastatud maailmas.<\/p>\n

      <\/p>\n

      Kuid naaseme algse \u00fclesande juurde. Kui osa s\u00fcsteemist saab ehitada eventual consistency<\/a><\/noindex>, siis saab luua j\u00e4rgmise skeemi.<\/p>\n

      <\/p>\n

      \"Mugavad<\/p>\n

      <\/p>\n

      Selle l\u00e4henemise olulised omadused:<\/p>\n

      <\/p>\n