Tere, kolleegid.
Täna esitame teie ette Tugberk Ugurlu artikli tõlke, kus ta püüab lühidalt kokku võtta kaasaegsete tarkvarasüsteemide projekteerimise põhimõtted. Siin on, mida autor enda kohta ütleb:
Kuna on selgelt võimatu kajastada sellist hiiglaslikku teemat nagu arhitektuurimuster + projekteerimismustrid 2019. aasta seisuga, soovitame mitte ainult härra Ugurlu teksti, vaid ka mitmeid linke, mida ta seal hoolikalt välja on toonud. Kui teile meeldib - avaldame ka kitsama spetsialiseerumise tekstid jaotatud süsteemide projekteerimisest.
Pilt Unsplashi saidilt
Kui teil pole kunagi selliste väljakutsetega kokku puutunud nagu tarkvarasüsteemi projekteerimine nullist, siis võib töö alustamine mõnikord olla segane ja ebaselge. Mina usun, et esmalt tuleb määratleda piirid, et kuidagi kindlalt aru saada, mida täpselt soovite projekteerida, ja siis – rullida varrukad ja töötada, mitte neist piiridest väljuda. Hea lähtepunkt võiks olla mõni toode või teenus (ideaalis selline, mis teile väga meeldib) ja uurida selle teostust. Teid võib üllatada, kui lihtne see toode välja näeb, samas kui tegelikult on seal peidus tohutu keerukus. Ärge unustage: , ja see on normaalne.
Mõtleksin, et parim nõuanne, mida ma saan anda neile, kes alustavad süsteemi projekteerimist, on: ärge tehke mingeid eeldusi! Alates algusest on oluline konkreetselt määratleda faktid, mis selle süsteemi kohta on teada, ja sellega seotud ootused. Siin on mõned head küsimused, millele vastused aitavad teil projekteerimisega alustada:
- Mis on probleem, mida me proovime lahendada?
- Milline on maksimaalne kasutajate arv, kes meie süsteemiga suhtlevad?
- Milliseid andmete salvestamise ja lugemise mustreid me kasutame?
- Millised on oodatavad rikkejuhud ja kuidas me kavatseme nendega toime tulla?
- Millised on süsteemi järjepidevuse ja kättesaadavuse ootused?
- Kas on mingeid nõudeid, mis on seotud välishindamise ja regulatsiooniga, mida tuleb arvesse võtta?
- Milliseid konfidentsiaalseid andmevariante me kavatseme hoida?
Need on vaid mõned küsimused, mis on olnud kasulikud nii mulle kui ka meeskondadele, kellega olen aastate jooksul koos töötanud. Kui tead vastuseid nendele küsimustele (ja teistele, mis on selles kontekstis asjakohased), siis saame järk-järgult süveneda ülesande tehnilistesse detailidesse.
Seame algtaseme
Mida ma siin „algtaseme” all mõistan? Tõepoolest, tänapäeval on enamik tarkvaratööstuse probleeme „lahendatavad” juba olemasolevate meetodite ja tehnoloogiatega. Seega, juhindudes sellest maastikust, sa saad teatud eelise, silmitsi seistes ülesannetega, mida keegi on enne sind lahendanud. Pea meeles, et programmid kirjutatakse äriliste ja kasutajate probleemide lahendamiseks, seega püüame lahendada ülesande kõige vahetum ja lihtsam (kasutaja vaatenurgast) viisil. Miks on seda oluline meeles pidada? Võib-olla meeldib sulle oma koordinaatsüsteemis igaühe jaoks unikaalseid lahendusi otsida, kuna arvad, et „kui ma järgiksin mustritele, ei oleks ma tõeline programmeerija”? Tegelikult on kunst siin otsuste tegemises, kus ja mida teha. Loomulikult seisavad me kõik aeg-ajalt silmitsi ainulaadsete probleemidega, millest igaühel on oma väljakutsed. Kuid kui meie algtase on selgelt määratletud, teame, millele oma energia suunata: kas otsime valmis lahendusi probleemile või uurime seda sügavamalt, et paremini mõista.
Mõtle, et mul õnnestus teid veenda, et kui spetsialist mõistab kindlalt, mis on mõne suurepärase tarkvarasüsteemi arhitektuuri komponent, siis on need teadmised hindamatud, et omandada arhitekti kunst ja luua tugev alus antud valdkonnas.
Hästi, kust alustada? omab GitHubis hoidlat nimega , mille materjalide põhjal saate õppida suurte süsteemide projekteerimist ja valmistuda sellele teemale suunatud vestlusteks. Hoidlas on sektsioon näidistega , kus käsitletakse, kuidas mõni tuntud ettevõte läheneb oma süsteemide kujundamisele, , näiteks Twitter, Uber jne.
Kuid enne kui liikuda selle materjali juurde, uurime lähemalt kõige olulisemaid arhitektuurilisi väljakutseid, millega praktikas silmitsi seistakse. See on tähtis, kuna tuleb täpsustada PALJU aspekte sellest keerulisest ja mitmetahulisest probleemist ning seejärel lahendada see antud süsteemi regulatsioonide kohaselt. , endine Facebooki töötaja, salvestas , kus jagas oma kogemusi sadade kandidaatide vaatamisest. Kuigi video käsitleb otseselt suurte süsteemide projekteerimist ja edukaid kriteeriume, mis on olulised sellise positsiooni kandidaadi leidmisel, on see siiski ammendav ressurss, et mõista, millised asjad on süsteemide projekteerimisel kõige olulisemad. Samuti pakun .
Koguge teadmisi andmete hoidmise ja väljavõtmise kohta.
Reeglina mõjutab teie otsus, kuidas andmeid pikaajaliselt salvestada ja edastada, süsteemi jõudlust kriitiliselt. Seetõttu peate kõigepealt mõistma andmete salvestamise ja lugemise ootusi teie süsteemis. Järgmiseks peate oskama neid näitajaid hinnata ja tegema valiku, tuginedes nendele hinnangutele. Kuid suudate seda ülesannet tõhusalt täita ainult siis, kui tunnete andmete salvestamise olemasolevaid mustreid. Põhimõtteliselt tähendab see kindlate teadmist, mis on seotud .
Andmebaase saab pidada andmestruktuurideks, mis omavad erakordset skaleeritavust ja vastupidavust. Seetõttu peab andmestruktuuride teadmine teile olema äärmiselt kasulik ka andmebaaside valimisel. Näiteks, – on andmestruktuuride server, mis toetab erinevaid väärtuste tüüpe. See võimaldab töötada selliste andmestruktuuridega nagu loendid ja hulgad, lugeda andmeid tuntud algoritmide abil, näiteks , korraldades sellist tööd pikaajalise ja kõrge kättesaadavusega viisil.
Pilt Unsplashi saidilt
Kui olete erinevate andmesalvestuspatternditega piisavalt kursis, liikuge andmete järjepidevuse ja kättesaadavuse uurimisele. Esiteks peate omandama vähemalt üldiselt, seejärel täiendama oma teadmisi, uurides põhjalikumalt väljakujunenud mustreid ja . Nii saate teavet sel alal ning mõistate, et andmete lugemine ja kirjutamine on tegelikult kaks väga erinevat probleemi, millest igaüks toob endaga kaasa oma spetsiifilised väljakutsed. Varustatud mitmete järjepidevuse ja kättesaadavuse tagamise mudelitega, saate oluliselt tõsta süsteemi jõudlust, tagades samas andmete katkematu edastamise teie rakendustesse.
Lõpuks, lõpetades jutu andmemagamise küsimustest, tasub mainida ka vahemälu. Kas see peaks toimuma nii kliendis kui serveris? Millised andmed saavad olema teie vahemälus? Ja miks? Kuidas te organiseerite vahemälu tühistamise? Kas see toimub regulaarselt, teatud aja järel? Kui jah, siis kui sageli? Nende teemade uurimist soovitan alustada ülaltoodud süsteemide projekteerimise käsiraamatust.
Kommunikatsioonimustrid
Süsteemid koosnevad erinevatest komponentidest; need võivad olla erinevad protsessid, mis töötavad ühe ja sama füüsilise sõlme sees, või erinevad masinad, mis tegutsevad teie võrgu erinevates osades. Mõned neist ressurssidest teie võrgus võivad olla privaatsete, kuid teised peavad olema avalikud ja avatud tarbijatele, kes nendeni väljastpoolt pääsevad.
Oluline on tagada nende ressursside omavaheline suhtlemine ning informatsiooni vahetamine kogu süsteemi ja välismaailma vahel. Süsteemide projekteerimise kontekstis seisame ka siin silmitsi uute ainulaadsete väljakutsetega. Uurime, kuidas võivad olla kasulikud , ning millised r.
Pilt Unsplashi saidilt
Välismaailmaga suhtlemise korraldamisel on alati väga oluline , mille tagamiseks tuleb läheneda tõsiselt ja sellega aktiivselt tegeleda.
Ühenduste jaotamine
Ma ei ole kindel, kas selle teema esitlemine eraldi jaguna on kõigile õigustatud. Sellegipoolest tutvustan siin seda kontseptsiooni põhjalikult, pidades silmas, et selle jao materjal on kõige täpsemalt kirjeldatud termini "ühenduste jaotamine" (connection distribution) abil.
Süsteemid moodustuvad õigesti ühendatud komponentide hulgast, ning nende vaheline suhtlemine korraldatakse sageli kehtivate protokollide, näiteks TCP ja UDP alusel. Kuid neid protokolle üksi ei piisa sageli, et rahuldada kõiki tänapäevaste süsteemide vajadusi, mis töötavad sageli suure koormuse all ja sõltuvad tugevalt kasutajate vajadustest. Tihti on vajalik leida ühenduste jaotamise viise, et toime tulla selliste kõrgete koormustega süsteemis.
Selle jaotamise alus on tuntud (DNS). Selline süsteem võimaldab muundada domeeninime, kasutades näiteks kaalutud ümmargusi algoritme (weighted round robin) ja viivituse põhiseid meetodeid, mis aitavad koormust jaotada.
on oluline, ja praktiliselt iga suur süsteem Internetis, millega me täna kokku puutume, asub ühe või mitme koormuse tasakaalustaja taga. Koormuse tasakaalustajad aitavad jaotada kliendi päringud mitmete saadavalolevate instantside vahel. Koormuse tasakaalustajad võivad olla nii riistvaralised kui ka tarkvaralised, kuid praktikas puutume sagedamini kokku tarkvaralistega, näiteks ja . on kontseptuaalselt samuti väga sarnased koormuse tasakaalustajatele, kuigi nende vahel on rida . Neid erinevusi on kindlasti vaja arvesse võtta, projekteerides süsteemi teie vajadusi silmas pidades.
Samuti tuleks teada (CDN). CDN – see globaalne jaotatud proxy-serverite võrk, mis toimetab teavet nendest sõlmedest, mis asuvad konkreetse kasutaja lähedal. CDN-võrkude kasutamine on soovitatav, kui töötate staatiliste failidega, nagu JavaScript, CSS ja HTML. Lisaks on tänapäeval laialdaselt kasutusel pilveteenused, mis pakuvad liiklusjuhtimise lahendusi, näiteks , mis tagavad teile globaalse jaotuse ja vähendatud latentsuse dünaamilise sisu töötlemisel. Siiski on sellised teenused tavaliselt kasulikud olukordades, kus on vaja töötada seisundita veebiteenustega.
Räägime äriloogikast. Äriloogika, töövoogude ja komponentide struktureerimine
Nii et, oleme jõudnud arutada mitmesuguseid süsteemi infrastruktuurilisi aspekte. Tõenäoliselt ei pööra kasutaja nende süsteemi elementide üle pead ja ausalt öeldes ei muretse nende pärast üldsegi. Kasutajat huvitab see, kuidas teie süsteemiga suhelda, mida on võimalik saavutada, kui toimida teatud viisil, ja ka see, kuidas süsteem täidab kasutaja käske ning kuidas ja mida teeb kasutaja andmetega.
Nagu artikli pealkirjast selgub, kavatsen ma rääkida tarkvaraarhitektuurist ja süsteemide kavandamisest. Seetõttu ei olnud ma plaaninud käsitleda tarkvaraarenduspatente, mis kirjeldavad, kuidas programmeerimise komponente luuakse. Kuid mida rohkem ma sellele mõtlen, seda enam tundub mulle, et piir tarkvarapatentide ja arhitektuuriliste mustrite vahel on väga hägune ning need kaks kontseptsiooni on tihedalt seotud. Võtame näiteks, (event sourcing). Kui võtate selle arhitektuurimustri omaks, mõjutab see praktiliselt kõiki teie süsteemi aspekte: andmete pikaajaline säilitamine, süsteemis kehtiv kooskõlvusaste, komponentide struktuur jne. Seetõttu otsustasin mainida mõningaid arhitektuurimustreid, mis on otse seotud äri loogikaga. Kuigi selles artiklis pean võib-olla piirduma lihtsa loendiga, soovitan teil tutvuda sellega ja mõelda nende mustritega seotud ideedele. Palun vaadake:
- Kontseptsioonid , sealhulgas ,
Koostöö lähenemisviisid
On ebatakse, et te oleksite projekti ainus liige, kes vastutab süsteemi projekteerimise protsessi eest. Vastupidi, tõenäoliselt peate suhtlema kolleegidega, kes töötavad nii teie ülesande raames kui ka väljaspool seda. Sellisel juhul võib osutuda vajalikuks koos kolleegidega hinnata valitud tehnoloogilisi lahendusi, välja selgitada äri vajadused ja mõista, kuidas ülesandeid paremini jagada.
Pilt Unsplashi saidilt
Esimese asjana on vajalik välja töötada täpne ja laialdaselt tunnustatud arusaam sellest, milline on see äri eesmärk, mida proovite saavutada, ning milliste dünaamiliste elementidega tuleb teha koostööd. Grupi modelleerimise tehnikad, sealhulgas (event storming) aitavad märgatavalt kiirendada seda protsessi ja suurendavad teie edukuse tõenäosust. Selle tööga saab tegeleda enne või pärast seda, kui olete määratlenud , ja seejärel süvendada seda toote küpsemise käigus. Tuginedes siin saavutatud kooskõlastuse tasemele, saate samuti formuleerida teie kitsas kontekst, milles te töötate. Kui peate rääkima oma süsteemi arhitektuurist, võib teil olla abi , mille on esitanud , eriti kui peate mõistma, kui sügavale peate probleemide üksikasjadesse laskuma, visualiseerides asju, mida soovite edastada.
Tõenäoliselt on sellel teemal ka teisi küpsemaid tehnoloogiaid, mis on sama kasulikud kui objektorienteeritud projekteerimine. Kuid me naaseme lõpuks ikka ja taas valdkonna arusaamise juurde, seega on teadmised ja kogemused kasuks.
Allikas: habr.com
