{"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 arhitektuuri mustrid","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Tere, Habr!<\/p>\n

<\/p>\n

Praeguste koroonaviiruse t\u00f5ttu on mitmed veebiteenused hakanud saama suurenenud koormust. N\u00e4iteks \u00fcks kaubandusketi veebisait Suurbritannias lihtsalt sulges oma veebipoe<\/a><\/noindex>, kuna v\u00f5imsus ei piisanud. Kuid mitte alati ei saa serverit kiirendada, lihtsalt lisades v\u00f5imsamat riistvara, kuid kliendi p\u00e4ringud tuleb siiski t\u00f6\u00f6delda (v\u00f5i nad lahkuvad konkurentide juurde).<\/p>\n

<\/p>\n

Selles artiklis r\u00e4\u00e4gin l\u00fchidalt populaarsetest praktikatest, mis v\u00f5imaldavad luua kiire ja t\u00f6\u00f6kindla teenuse. Olen valinud ainult need arendusskeemid, millega on praegu lihtne tutvuda<\/strong>. Iga punkti jaoks on teil kas juba olemasolevad raamatukogud v\u00f5i v\u00f5imalus lahendada \u00fclesanne pilveplatvormi abil.<\/p>\n

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

Horisonitaalne skaleerimine<\/h1>\n

<\/p>\n

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

<\/p>\n

N\u00e4iteks v\u00f5tan ma abstraktse pilvefailide salvestuss\u00fcsteemi, st mingi analooge OwnCloudile, OneDrive'ile ja nii edasi.<\/p>\n

<\/p>\n

Allpool on standardne sarnase skeemi joonis, kuid see n\u00e4itab vaid s\u00fcsteemi keerukust. Peame kuidagi teenuseid s\u00fcnkroniseerima. Mis juhtub, kui kasutaja salvestab faili tahvelarvutist ja soovib seda seej\u00e4rel mobiilik\u00f5nest vaadata?<\/p>\n

<\/p>\n

\"Mugavad
\nL\u00e4henemiste vahe: vertikaalses skaleerimises oleme valmis s\u00f5lmede v\u00f5imsust suurendama, samas kui horisontraalses skaleerimises lisame uusi s\u00f5lmi, et koormust jaotada.<\/p>\n

<\/p>\n

CQRS<\/h1>\n

<\/p>\n

Command Query Responsibility Segregation<\/a><\/noindex> on \u00fcsna t\u00e4htis muster, sest see v\u00f5imaldab erinevatel klientidel mitte ainult \u00fchendada erinevatel teenustel, vaid ka saada samasuguseid s\u00fcndmuste vooge. Selle eelised pole lihtsa rakenduse jaoks nii selged, kuid see on \u00e4\u00e4rmiselt t\u00e4htis (ja lihtne) koormatud teenuse jaoks. Selle olemus: sisenevad ja v\u00e4ljuvad andmevood ei tohiks kattuda. Te ei saa saata p\u00e4ringut ja oodata vastust, selle asemel saadate p\u00e4ringu teenusesse A, kuid saate vastuse teenusest B.<\/p>\n

<\/p>\n

K\u00e4esoleva l\u00e4henemise esimene eelis on v\u00f5imalus katkestada \u00fchendus (sellest s\u00f5nastuses) pika p\u00e4ringu t\u00e4itmise ajal. N\u00e4iteks v\u00f5tame enam-v\u00e4hem standardse j\u00e4rjestuse:<\/p>\n

<\/p>\n

    \n
  1. Kliendilt saadeti p\u00e4ring serverisse.<\/li>\n
  2. Server alustas pika t\u00f6\u00f6tlemisega.<\/li>\n
  3. Server vastas kliendile tulemusega.<\/li>\n<\/ol>\n

    <\/p>\n

    Kujutame ette, et punktis 2 toimus \u00fchenduse katkestamine (v\u00f5i v\u00f5rk taask\u00e4ivitas, v\u00f5i kasutaja liikus teisele lehele, katkestades \u00fchenduse). Sellisel juhul on serveril keeruline saata vastust kasutajale teabega selle kohta, mis tegelikult t\u00f6\u00f6tati. CQRSi rakendamisel on j\u00e4rjestus veidi erinev:<\/p>\n

    <\/p>\n

      \n
    1. Klient tellis v\u00e4rskendused.<\/li>\n
    2. Kliendilt saadeti p\u00e4ring serverisse.<\/li>\n
    3. Server vastas \"p\u00e4ring aktsepteeritud\".<\/li>\n
    4. Server vastas tulemusega punkti \"1\" kaudu.<\/li>\n<\/ol>\n

      <\/p>\n

      \"Mugavad<\/p>\n

      <\/p>\n

      Nagu n\u00e4ha, on skeem veidi keerulisem. Veelgi enam, intuitiivne p\u00e4ring-vastus l\u00e4henemine puudub. Kuid nagu n\u00e4ha, ei too \u00fchenduse katkestamine p\u00e4ringu t\u00f6\u00f6tlemise ajal kaasa viga. Veelgi enam, kui kasutaja on tegelikult \u00fchendatud teenusega mitmest seadmest (n\u00e4iteks mobiiltelefonist ja tahvelarvutist), on v\u00f5imalik korraldada nii, et vastus tuleb m\u00f5lemale seadmele.<\/p>\n

      <\/p>\n

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

      <\/p>\n

      Kuid tegelikult saame me lisaboonuseid seoses sellega, et \u00fchesuunalist voogu on v\u00f5imalik t\u00f6\u00f6delda funktsionaalsti (kasutades RX ja analooge). Ja see on juba t\u00f5sine eelis, kuna p\u00f5him\u00f5tteliselt saab rakenduse teha t\u00e4ielikult reaktiivseks, kasutades samas funktsionaalset l\u00e4henemist. Suuremate programmide jaoks v\u00f5ib see oluliselt s\u00e4\u00e4sta arenduse ja hoolduse ressursse.<\/p>\n

      <\/p>\n

      Kui kombineerite seda l\u00e4henemist horisontaalse skaleerimisega, saame boonusena v\u00f5imaluse saata p\u00e4ringud \u00fche serveri kaudu, samas kui vastuseid saab teiselt. Seega v\u00f5ib klient ise valida endale sobiva teenuse, kuid s\u00fcsteem suudab ikkagi s\u00fcndmusi \u00f5igesti t\u00f6\u00f6delda.<\/p>\n

      <\/p>\n

      S\u00fcndmuste allikaks<\/h1>\n

      <\/p>\n

      Nagu te teate, on jaotatud s\u00fcsteemi \u00fcheks peamiseks omaduseks \u00fchise aja ja \u00fchise kriitilise sektsiooni puudumine. \u00dche protsessi puhul saate teha s\u00fcnkroniseerimise (samade muteksitega), mille jooksul olete kindel, et keegi teine ei k\u00e4ita seda koodi. Kuid jaotatud s\u00fcsteemi jaoks on see ohtlik, kuna see toob kaasa kulusid ning h\u00e4vitab skaaleerimise v\u00f5lu \u2013 k\u00f5iki komponente sunnitakse ikkagi ootama \u00fcht ja sama.<\/p>\n

      <\/p>\n

      Seega saame olulise fakti \u2013 kiiret jaotatud s\u00fcsteemi ei saa s\u00fcnkroniseerida, sest siis v\u00e4hendame tootlikkust. Teisest k\u00fcljest on meil sageli vajaliku teatud komponentide koosk\u00f5la. Ja selleks saame kasutada l\u00e4henemist eventual consistency<\/a><\/noindex>, kus garanteeritakse, et andmete muutuste puudumisel mingis ajavahemikus p\u00e4rast viimast uuendamist (\u201el\u00f5puks\u201d) tagastavad k\u00f5ik p\u00e4ringud viimase uuendatud v\u00e4\u00e4rtuse.<\/p>\n

      <\/p>\n

      Oluline on m\u00f5ista, et klassikalistes andmebaasides rakendatakse sageli ranget koosk\u00f5la<\/a><\/noindex>, kus iga s\u00f5lm omab samu andmeid (see saavutatakse sageli juhul, kui tehingut peetakse kehtivaks alles p\u00e4rast teise serveri vastust). Siin on teatud leevendused isolatsioonitasemete t\u00f5ttu, kuid \u00fcldine m\u00f5te j\u00e4\u00e4b samaks \u2013 saate elada t\u00e4ielikult 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