Tere, Habr!

Praeguste koroonaviiruse tõttu on mitmed veebiteenused hakanud saama suurenenud koormust. Näiteks üks kaubandusketi veebisait Suurbritannias lihtsalt sulges oma veebipoe, kuna võimsus ei piisanud. Kuid mitte alati ei saa serverit kiirendada, lihtsalt lisades võimsamat riistvara, kuid kliendi päringud tuleb siiski töödelda (või nad lahkuvad konkurentide juurde).

Selles artiklis räägin lühidalt populaarsetest praktikatest, mis võimaldavad luua kiire ja töökindla teenuse. Olen valinud ainult need arendusskeemid, millega on praegu lihtne tutvuda. Iga punkti jaoks on teil kas juba olemasolevad raamatukogud või võimalus lahendada ülesanne pilveplatvormi abil.

Horisonitaalne skaleerimine

Kõige lihtsam ja kõigile tuntud punkt. Üldiselt on kaks kõige levinumat koormuse jaotamise skeemi — horisonitaalne ja vertikaalne skaleerimine. Esimeses juhul lastakse teenustel töötada paralleelselt, jaotades seeläbi koormuse nende vahel. Teises tellite võimsamaid servereid või optimeerite koodi.

Näiteks võtan ma abstraktse pilvefailide salvestussüsteemi, st mingi analooge OwnCloudile, OneDrive'ile ja nii edasi.

Allpool on standardne sarnase skeemi joonis, kuid see näitab vaid süsteemi keerukust. Peame kuidagi teenuseid sünkroniseerima. Mis juhtub, kui kasutaja salvestab faili tahvelarvutist ja soovib seda seejärel mobiilikõnest vaadata?

Lähenemiste vahe: vertikaalses skaleerimises oleme valmis sõlmede võimsust suurendama, samas kui horisontraalses skaleerimises lisame uusi sõlmi, et koormust jaotada.

CQRS

Command Query Responsibility Segregation on üsna tähtis muster, sest see võimaldab erinevatel klientidel mitte ainult ühendada erinevatel teenustel, vaid ka saada samasuguseid sündmuste vooge. Selle eelised pole lihtsa rakenduse jaoks nii selged, kuid see on äärmiselt tähtis (ja lihtne) koormatud teenuse jaoks. Selle olemus: sisenevad ja väljuvad andmevood ei tohiks kattuda. Te ei saa saata päringut ja oodata vastust, selle asemel saadate päringu teenusesse A, kuid saate vastuse teenusest B.

Käesoleva lähenemise esimene eelis on võimalus katkestada ühendus (sellest sõnastuses) pika päringu täitmise ajal. Näiteks võtame enam-vähem standardse järjestuse:

1. Kliendilt saadeti päring serverisse.
2. Server alustas pika töötlemisega.
3. Server vastas kliendile tulemusega.

Kujutame ette, et punktis 2 toimus ühenduse katkestamine (või võrk taaskäivitas, või kasutaja liikus teisele lehele, katkestades ühenduse). Sellisel juhul on serveril keeruline saata vastust kasutajale teabega selle kohta, mis tegelikult töötati. CQRSi rakendamisel on järjestus veidi erinev:

1. Klient tellis värskendused.
2. Kliendilt saadeti päring serverisse.
3. Server vastas "päring aktsepteeritud".
4. Server vastas tulemusega punkti "1" kaudu.

Nagu näha, on skeem veidi keerulisem. Veelgi enam, intuitiivne päring-vastus lähenemine puudub. Kuid nagu näha, ei too ühenduse katkestamine päringu töötlemise ajal kaasa viga. Veelgi enam, kui kasutaja on tegelikult ühendatud teenusega mitmest seadmest (näiteks mobiiltelefonist ja tahvelarvutist), on võimalik korraldada nii, et vastus tuleb mõlemale seadmele.

Mis on huvitav, on see, et sissetulevate sõnumite töötlemise kood muutub sama (mitte 100%) nii klientide poolt mõjutatud sündmuste kui ka teiste sündmuste jaoks, sealhulgas teiste klientide poolt.

Kuid tegelikult saame me lisaboonuseid seoses sellega, et ühesuunalist voogu on võimalik töödelda funktsionaalsti (kasutades RX ja analooge). Ja see on juba tõsine eelis, kuna põhimõtteliselt saab rakenduse teha täielikult reaktiivseks, kasutades samas funktsionaalset lähenemist. Suuremate programmide jaoks võib see oluliselt säästa arenduse ja hoolduse ressursse.

Kui kombineerite seda lähenemist horisontaalse skaleerimisega, saame boonusena võimaluse saata päringud ühe serveri kaudu, samas kui vastuseid saab teiselt. Seega võib klient ise valida endale sobiva teenuse, kuid süsteem suudab ikkagi sündmusi õigesti töödelda.

Sündmuste allikaks

Nagu te teate, on jaotatud süsteemi üheks peamiseks omaduseks ühise aja ja ühise kriitilise sektsiooni puudumine. Ühe protsessi puhul saate teha sünkroniseerimise (samade muteksitega), mille jooksul olete kindel, et keegi teine ei käita seda koodi. Kuid jaotatud süsteemi jaoks on see ohtlik, kuna see toob kaasa kulusid ning hävitab skaaleerimise võlu – kõiki komponente sunnitakse ikkagi ootama üht ja sama.

Seega saame olulise fakti – kiiret jaotatud süsteemi ei saa sünkroniseerida, sest siis vähendame tootlikkust. Teisest küljest on meil sageli vajaliku teatud komponentide kooskõla. Ja selleks saame kasutada lähenemist eventual consistency, kus garanteeritakse, et andmete muutuste puudumisel mingis ajavahemikus pärast viimast uuendamist („lõpuks”) tagastavad kõik päringud viimase uuendatud väärtuse.

Oluline on mõista, et klassikalistes andmebaasides rakendatakse sageli ranget kooskõla, kus iga sõlm omab samu andmeid (see saavutatakse sageli juhul, kui tehingut peetakse kehtivaks alles pärast teise serveri vastust). Siin on teatud leevendused isolatsioonitasemete tõttu, kuid üldine mõte jääb samaks – saate elada täielikult kooskõlastatud maailmas.

Kuid naaseme algse ülesande juurde. Kui osa süsteemist saab ehitada eventual consistency, siis saab luua järgmise skeemi.

Selle lähenemise olulised omadused:

• Iga sissetulev päring paigutatakse ühte järjekorda.
• Päringu töötlemise käigus võib teenus ka ülesandeid paigutada teistesse järjekordadesse.
• Igal sissetulekul on identifikaator (mis on vajalik de-duplikatsiooniks).
• Järjekord töötab ideeliselt „append only” süsteemi kaudu. Sealt ei saa elemente kustutada ega ümber paigutada.
• Järjekord töötab FIFO skeemis (vabandust tautoloogia eest). Kui on vajalik samaaegne täitmine, tuleb ühel etapi käigus objektid erinevatesse järjekordadesse ümber paigutada.

Tuletan meelde, et analüüsime veebipõhise failide salvestamise juhtumit. Sel juhul näeb süsteem välja umbes selline:

Oluline on see, et diagrammil olevad teenused ei tähenda tingimata eraldi serverit. Ka protsess võib olla sama. Oluline on hoopis see, et ideoloogiliselt on need asjad eraldatud nii, et horisontaalne skaleerimine oleks lihtne rakendada.

Kaks kasutajat saavad skeemi, kus teenused, mis on mõeldud erinevatele kasutajatele, on erinevate värvidega tähistatud:

Sellise kombinatsiooni boonused:

• Teabe töötlemise teenused on eraldatud. Ootesüsteemid on samuti eraldatud. Kui me peame suurendama süsteemi läbilaskevõimet, piisab vaid rohkemate teenuste käivitamisest suuremal arvul serverites.
• Kuna me saame teavet kasutajalt, ei pea me tingimata ootama, kuni andmed on täielikult salvestatud. Vastupidi, me võime vastata lihtsalt „okei” ja alustada tööd järk-järgult. Samuti sujuvdab ootesüsteem tippe, kuna uue objekti lisamine toimub kiiresti ja kasutaja ei pea ootama kogu tsükli läbimist.
• Näiteks lisasin teenuse deduplikatsiooni, mis üritab sama faili kokku liita. Kui see töötab pikka aega 1% juhtudest, ei pane klient seda peaaegu tähele (vt. ülal), mis on suur pluss, kuna meeltme nõuda 100% kiirus ja usaldusväärsus.

Kuid koheselt paistavad välja ka miinused:

• Meie süsteemil puudub rangelt kooskõla. See tähendab, et kui näiteks liituda erinevate teenustega, võib teoreetiliselt saada erineva seisundi (kuna üks teenus ei pruugi jõuda teate vastuvõtmiseni sisemisest ootesüsteemist). Teise tagajärjena ei ole süsteemil enam ühtegi ühise aega. See tähendab, et näiteks ei saa kõiki sündmusi järjestada lihtsalt saabumise aja järgi, kuna kellad serverite vahel ei pruugi olla sünkroonsed (veelgi enam, sama kellaaeg kahel serveril on utoopia).
• Ükski sündmus ei saa nüüd lihtsalt tagasi võtta (nagu võiks teha andmebaasi puhul). Selle asemel on vajalik lisada uus sündmus — compensation event, mis muudab viimase seisundi vajalikuks. Sarnases valdkonnas näiteks: ilma ajalugu ümber kirjutamata (mis võib olla halb mitmel juhul) ei saa gitis tagasipöördumist teha, kuid saab teha erilise rollback commit, mis on sisuliselt lihtsalt vanema oleku taastamine. Siiski jääb ajalukku nii vale commit kui ka rollback.
• Andmeskeem võib muutuda versioonist versiooni, kuid vanade sündmuste uuendamine uue standardiga ei õnnestu (kuna sündmusi ei saa põhimõtteliselt muuta).

Nagu näha, sobib Event Sourcing suurepäraselt kokku CQRS-iga. Veelgi enam, süsteemi rakendamine tõhusate ja mugavate järjekordadega, kuid ilma andmevoogude eraldamiseta, on juba iseenesest keeruline, kuna tuleb lisada sünkroonimispunkte, mis vähendavad kogu järjekordade positiivset mõju. Rakendades mõlemat lähenemist korraga, peab programmi töö kodeerimist veidi kohandama. Meie puhul, kui saadame faili serverisse, tuleb vastusena ainult 'ok', mis tähendab vaid, et 'faili lisamise operatsioon on salvestatud'. Formaalset see ei tähenda, et andmed oleksid juba muudel seadmetel kättesaadavad (nt deduplication teenus võib indeksi ümber kohandada). Siiski, mõne aja pärast saab klient teadet stiilis 'fail X on salvestatud'.

Tulemuseks:

• Failide saatmise staatuste arv suureneb: klassikalise 'fail saadetud' asemel saame kaks: 'fail on lisatud serveri järjekorda' ja 'fail on salvestatud salvestusse'. Viimane tähendab, et teised seadmed saavad faili juba alustada (arvestades, et järjekorrad töötavad erineva kiirusel).
• Kuna teave saatmise kohta tuleb nüüd erinevate kanalite kaudu, peame välja mõtlema lahendused, et saada faili töötlemise staatus. Selle tagajärjel: erinevalt klassikalisest request-response mudelist võib klient faili töötlemise ajal taaskäivituda, kuid selle töötlemise staatus jääb õigeteks. Ja see punkt töötab põhimõtteliselt karbist välja. Tulemuseks: oleme nüüd tõrgete suhtes tolerantsemad.

Sharding

Nagu eespool mainitud, puudub event sourcing süsteemides range kooskõla. Seega saame kasutada mitmeid salvestusi ilma nende vahelise sünkroniseerimiseta. Meie ülesandele lähenedes saame:

• Jagada faile tüüpide järgi. Näiteks pilte/ Videoid saab dekodeerida ja valida tõhusama vormingu.
• Jagab kontosid riikide järgi. Paljude seaduste tõttu võib see osutuda vajalikuks, kuid antud arhitektuuriline skeem annab selle võimaluse automaatselt.

Kui soovite andmeid ühest hoidlast teise viia, siis ei saa tavapäraste vahenditega hakkama. Kahjuks on sel juhul vajalik peatada järjekord, teha migreerimine ja seejärel käivitada see uuesti. Üldiselt ei saa andmeid "režiimis" üle kanda, kuid kui sündmuste järjekord säilitatakse täielikult ja teil on eelneva oleku koopiad, siis saame sündmusi taasesitada järgmiselt:

• Event Source'is on igal sündmusel oma identifikaator (ideaalis - mitte kahanev). Seega saame hoidlas lisada välja - viimase töödeldud elemendi id.
• Kopeerime järjekorra, et kõik sündmused saaksid töötlemiseks suunata mitu sõltumatut hoidlat (esimene on see, kus andmed praegu asuvad, ja teine on uus, kuid hetkel tühi). Teine järjekord ei ole loomulikult praegu töödeldud.
• Käivitame teise järjekorra (see tähendab, et alustame sündmuste taasesitamist).
• Kui uus järjekord on suhteliselt tühi (st. keskmine erinevus aja osas elemendi lisamise ja selle väljavõtmise vahel on vastuvöetav), siis võib hakata lugejaid suunama uude hoidlasse.

Kuidas nähtud, ei ole meie süsteemis olnud ega ole ka ranget järjepidevust. On olemas ainult eventual consistency, st. garantii, et sündmused töödeldakse sama järjekorraga (kuid võimaliku erineva viivitusega). Kasutades seda, suudame andmeid suhteliselt kergesti üle kanda ilma süsteemi seiskamiseta teisele poole maakera.

Nii et jätkates meie näidet failide veebihoiust, annab sarnane arhitektuur meile juba mitmeid boonuseid:

• Saame objekti liikuda lähemale kasutajatele, dünaamiliselt. Seeläbi saab parandada teenuse kvaliteeti.
• Saame hoida osa andmeid ettevõtte sees. Näiteks nõuavad ettevõtte kasutajad sageli, et nende andmed jääksid kontrolli all olevatesse andmekeskustesse (andmelekkete vältimiseks). Tõkestamise tõttu saame seda hõlpsasti toetada. Ja ülesanne muutub veelgi lihtsamaks, kui kliendil on ühilduv pilv (nt. Azure self hosted).
• Ja kõige tähtsam on, et me ei pea seda tegema. Alustuseks piisab meile ühest salvest, et alustada tööga kiiremini. Ja selle süsteemi peamine omadus on see, et kuigi see on laienev, on see algfaasis piisavalt lihtne. Lihtsalt pole vaja kohe kirjutada koodi, mis töötab miljoni eraldi iseseisva järjekorraga jne. Kui see osutub vajalikuks, on seda võimalik tulevikus teha.

Kliendi staatilise sisu hostimine

Seda punkti võib pidada iseenesest mõistetavaks, kuid see on siiski vajalik enam-vähem standardse koormusega rakenduse jaoks. Selle olemus on lihtne: kogu staatiline sisu jagatakse mitte samalt serverilt, kus rakendus asub, vaid spetsiaalsetelt, just selleks otstarbeks määratud serveritelt. Sellest tulenevalt toimub neid toiminguid kiiremini (näiteks nginx toimetab faile kiiremini ja odavamalt kui Java-server). Plussiks on, et CDN (Sisu edastamise võrk) arhitektuur võimaldab paigutada meie failid lähemale lõppkasutajatele, mis avaldab positiivset mõju teenusega töötamise mugavusele.

Kõige lihtsam ja tavapärasem näide staatilisest sisust on komplekt skripte ja pilte veebisaidile. Nende puhul on kõik lihtne — need on ette teada, seejärel arhiiv laaditakse üles CDN-serveritesse, kust neid jagatakse lõppkasutajatele.

Kuid tegelikult on staatilise sisu jaoks võimalik rakendada lähenemist, mis on midagi sarnast lambda-arhitektuurile. Tagasi keerukuse juurde (veebifailide salvestamine), kus meil on vaja jagada faile kasutajatele. Lihtsaim lahendus oleks luua teenus, mis iga kasutaja päringu jaoks teeb kõik vajalikud kontrollid (autentimine jne), ja seejärel laadib faili otse meie salvestusest. Selle lähenemise peamine puudus on, et staatiline sisu (teatud versiooniga fail on põhimõtteliselt staatiline sisu) jagatakse samalt serverilt, mis sisaldab äriloogikat. Selle asemel saab luua järgmise skeemi:

• Server väljastab allalaadimise URL-i. See võib olla kujul file_id + võti, kus võti on väike digitaalne allkiri, mis annab õiguse ressursile ligipääsemiseks järgmise 24 tunni jooksul.
• Faili edastamise eest hoolitseb lihtne nginx järgmiste valikutega:
  • Sisu kaevandamine. Kuna see teenus võib asuda eraldi serveris, oleme me endale jätnud tulevikuplaanid, et hoida kõik hiljuti alla laaditud failid kettal.
  • Tõemanus võtme kontrollimine ühenduse loomise ajal
• Valikuline: sisu voogedastus. Näiteks, kui me tihendame kõik failid teenuses, siis saab dekompressiooni teha otse selles moodulis. Seetõttu IO operatsioonid toimuvad seal, kus need on vajalikud. Java arhiivija võib kasutada palju lisa mälumahtu, kuid teenuse ümberkirjutamine äri loogikale kanti Rust / C++ võib osutuda samuti ebaefektiivseks. Meie puhul kasutatakse erinevaid protsesse (või isegi teenuseid), seega saab efektiivselt eristada äri loogikat ja IO operatsioone.

Selline skeem ei sarnane väga staatilise sisu jagamisega (kuna me ei lae kogu staatikat kuhugi), kuid reaalses elus tegeleb see lähenemine just muutumatute andmete jagamisega. Veelgi enam, seda skeemi saab laiendada ka teistele juhtumitele, kus sisu ei ole lihtsalt staatiline, vaid võib esitada muutumatute ja kustutamatute plokkidena (kuigi neid võib lisada).

Teise näitena (kinnitamiseks): kui olete töötanud Jenkins'i / TeamCity'ga, siis teate, et mõlemad lahendused on kirjutatud Java-s. Mõlemad on Java-protsess, mis tegeleb nii buildide orkestreerimise kui ka sisu haldamisega. Eriti neil on ülesanded nagu 'edastada fail / kaust serverilt'. Näiteks: artefaktide väljastamine, allika koodi edastamine (kui agent ei laadi koodi otse hoidlast, vaid server teeb seda tema eest), juurdepääs logidele. Kõik need ülesanded erinevad IO koormusest. See tähendab, et server, mis vastutab keerulise äri loogika eest, peab suutma tõhusalt suunata suuri andmevoogusid. Ja mis kõige huvitavam, sellise operatsiooni saab delegaatsida sama nginx-i just selle sama skeemi kohaselt (välja arvatud, et päringule tuleb lisada andmevõti).

Kuid kui naasta meie süsteemi juurde, siis saame sellise skeemi:

Nagu näha, on süsteem radikaalselt keerukamaks muutunud. See ei ole enam lihtsalt mini-protsess, mis salvestab faile kohapeal. Nüüd on vajalik mitte kõige lihtsam tugi, API versioonide kontroll ja nii edasi. Seetõttu, pärast kõigi diagrammide joonistamist, on kõige parem detailselt hinnata, kas sarnased kulud on õigustatud. Kui soovite süsteemi laienemise võimalusi (sealhulgas suurenenud kasutajate arvu toetamiseks), peate kaaluma selliste lahenduste kasutuselevõttu. Kuid tulemuseks on see, et arhitektuuriline süsteem on valmis koormuse suurendamiseks (peaaegu iga komponent on võimalik horisontaalselt kloneerida). Süsteemi saab uuendada selle peatamata (lihtsalt mõned toimingud aeglustuvad veidi).

Nagu ma juba alguses rääkisin, on mitmed internetiteenused hakanud kogema suurenenud koormust. Ja mõned neist on lihtsalt lõpetanud korraliku töö. Tegelikult kukkusid süsteemid kokku just siis, kui äri peaks raha teenima. See tähendab, et asemel, et edasi lükata kohaletoimetamine, ning pakkuda klientidele 'planeerige kohaletoimetamist järgmiste kuude jooksul', ütles süsteem lihtsalt 'minge konkurentide juurde'. See ongi madala jõudluse hind: kaotused ilmnevad just siis, kui kasum oleks kõrgeim.

Kokkuvõte

Kõik need lähenemisviisid on olnud juba varem tuntud. Näiteks VK on juba ammu kasutanud staatilise sisu hostimise ideed piltide jagamiseks. Hulgaliselt veebimänge kasutavad fragmentimist (Sharding) mängijate jagamiseks piirkondade vahel või mängukohtade jagamiseks (kui maailm on ühtne). Event sourcing lähenemist kasutatakse aktiivselt e-posti teenustes. Enamik kauplejate rakendusi, kuhu voolab pidevalt andmeid, põhinevad tegelikult CQRS lähenemisel, et saaks filtreerida saadud andmeid. Ja horisontaalset skaleerimist on juba pikka aega rakendatud paljudes teenustes.

Kuid kõige tähtsam on see, et kõiki neid mustreid on modernsetes rakendustes väga lihtne rakendada (kui need on loomulikult asjakohased). Pilvandmed pakuvad Sharding'i ja horisontaalset skaleerimist koheselt, mis on oluliselt lihtsam kui tellida erinevaid eriservereid erinevates andmekeskustes iseseisvalt. CQRS on nüüd kergem, vähemalt tänu selliste raamatukogude arengule nagu RX. Kümme aastat tagasi suutis harva ükski veebisait selliseid asju toetada. Event Sourcing'i seadistamine on samuti uskumatult lihtne tänu juba olemasolevatele konteineritele koos Apache Kafka'ga. Kümme aastat tagasi oleks see olnud innovatsioon, nüüd on see igapäevane praktika. Samuti ka staatilise sisu hostimine: mugavamate tehnoloogiate tõttu (sealhulgas põhjaliku dokumentatsiooni ja suure vastuste baasi olemasolu tõttu) on selline lähenemine muutunud veelgi lihtsamaks.

Kokkuvõtteks, mitmete üsna keeruliste arhitektuurimustrite rakendamine on nüüd oluliselt lihtsam, mis tähendab, et sellele tasub varakult tähelepanu pöörata. Kui kümne aasta vanuses rakenduses loobuti mõnest ülalkirjeldatud lahendusest kõrgete rakendamise ja hoolduskulude tõttu, siis nüüd, uues rakenduses või pärast refaktorimist, on võimalik luua teenus, mis on arhitektuuriliselt nii skaleeritav (tõhususe vaatenurgast) kui ka valmis klientide uute nõudmiste jaoks (näiteks isikuandmete lokaliseerimiseks).

Ja kõige tähtsam: palun ärge kasutage neid lähenemisviise, kui teil on lihtne rakendus. Jah, need on ilusad ja huvitavad, kuid saidile, mille tippkülastus on 100 inimest, võib sageli piisata klassikalisest monoliidist (vähemalt väljastpoolt, seestpoolt saab kõik mooduliteks jagada jne).

Allikas: habr.com