Tere, kolleegid.
Täna esitame teie tähelepanu tõlke Tugberk Ugurlu artiklist, kus on võrreldes väiksema mahuga välja toodud kaasaegsete tarkvarasüsteemide projekteerimise põhimõtted. Siin on, mida autor enda kohta ütleb.
Kuna sellise kolossaalset teemat, nagu arhitektuurilised mustrid + projekteerimise mustrid aastaks 2019, on võimatu hajutada, soovitame mitte ainult härra Ugurlu teksti, vaid ka rohkelt linke, mille ta lahkesti esitanud on. Kui see teile meeldib, avaldame ka kitsama eriteema tekstid jaotatud süsteemide projekteerimise kohta.
Pilt Unsplashi saidilt
Kui te pole kunagi silmitsi seisnud selliste väljakutsetega nagu tarkvarasüsteemi projekteerimine nullist, siis alustades sellist tööd ei ole mõnikord isegi selge, kust alustada. Usun, et esmalt on vajalik joonistada piirid, et enam-vähem kindlalt mõista, mida te täpselt projekteerima hakkate, ja seejärel – rullida üles varrukad ja töötada, jäädes nende piiride sisse. Aluspunktiks võib võtta mõne toote või teenuse (ideaalis – sellise, mis teile väga meeldib) ja analüüsida selle teostust. Võib-olla imestate, kui lihtne see toode välja näeb ning kui suur keerukus selles tegelikult peitub. Ärge unustage: , ja see on normaalne.
Arvan, et parim nõuanne neile, kes alustavad süsteemi projekteerimist, on: ärge tehke mingeid oletusi! Alates esimesest hetkest on oluline täpsustada faktid, mis on selle süsteemi kohta teada, ja sellega seotud ootused. Siin on mõned head küsimused, millele vastamine aitab teil projekti alustada:
- Mis on probleem, mida me püüame lahendada?
- Kui palju kasutajaid suudab meie süsteem korraga taluda?
- Milliseid andmete kirjutamise ja lugemise mustreid me kasutama hakkame?
- Millised on oodatavad tõrkeolukorrad ja kuidas me plaanime nendega toime tulla?
- Millised ootused kehtivad süsteemi järjepidevuse ja kättesaadavuse osas?
- Kas tuleb töö käigus arvesse võtta mingeid nõudeid, mis on seotud välistest kontrollidest ja regulatsioonidega?
- Milliseid konfidentsiaalsete andmete vorme me kavatseme salvestada?
Need on vaid mõned küsimused, mis on olnud abiks nii mulle kui ka meeskondadele, kellega olen aastate jooksul töötanud. Kui tead vastuseid neile küsimustele (ja teistele, mis on kontekstis, kus sa töötad, asjakohased), saad süveneda tehnilistele detailidele.
Seame algtaseme
Mida mõistan ma siin «algtaseme» all? Tänapäeval on enamik tarkvarainstitutsioonide probleeme «lahendatavad» juba olemasolevate meetodite ja tehnoloogiate abil. Seega, selle maastiku tundmine annab sulle teatud eelise, kui puutud kokku probleemidega, mida keegi teine on enne sind lahendanud. Pea meeles, et programmid on kirjutatud äri- ja kasutajaprobleemide lahendamiseks, seega püüame lahendust leida kõige otsemal ja lihtsamal (kasutaja seisukohalt) viisil. Miks on seda oluline meeles pidada? Võib-olla sulle meeldib oma koordinaatides leida ainulaadseid lahendusi igale probleemile, arvates, et «kuidas ma saan olla programmeerija, kui järgnen kõigile mustritele»? Tegeliselt, kunsti seisneb siin otsuste tegemises, kus ja mida teha. Loomulikult seisavad meie ees aeg-ajalt unikaalsed probleemid, igaüks neist on tõeline väljakutse. Kuid kui meie algtase on selgelt piiritletud, teame, kuhu investeerida: kas valmis lahenduste leidmiseks või probleemi sügavamaks uurimiseks ja mõistmiseks.
Arvan, et mul on õnnestunud sind veenda, et kui spetsialist mõistab kindlalt aru saada, milline on teatud suurepäraste tarkvarasüsteemide arhitektuuriline omadus, siis need teadmised on hindamatud arhitektuuri kunsti omandamisel ja selle valdkonna kindla alusbaasi loomisel.
No hästi, kust alustada? Ü on loonud GitHubis hoidla nimega , mille materjalide abil saad õppida suurte süsteemide projekteerimist ja valmistuda intervjuudeks selle teema kohta. Hoidlas on jaotis näidete , kus arutatakse, kuidas organisatsioonid oma süsteemide disainile lähenevad , nagu Twitter, Uber jne.
Kuid enne selle sisu juurde liikumist tasub lähemalt uurida kõige olulisemaid arhitektuurilisi väljakutseid, millega praktikas silmitsi seistakse. See on oluline, kuna tuleb täpsustada PALJU aspekte, mis on keerulise ja mitmekesise probleemi osa, ning seejärel lahendada see antud süsteemis kehtivate regulatsioonide raames. , endine Facebooki töötaja, salvestas , kus ta jagas oma isiklikku kogemust sadade kandidaatide läbivaatamisel. Kuigi video käsitleb selgelt suurte süsteemide disaini ja eduka kandidaadi valimise kriitereid, tuleb see siiski põhjalikuks allikaks selle kohta, mis on kõige tähtsam süsteemide disainimisel. Samuti pakun selle video kokkuvõtet.
Koguge teadmisi andmete salvestamisest ja väljastamisest
Üldiselt mõjutab teie otsus, kuidas te soovite oma andmeid pikaajaliselt salvestada ja edastada, süsteemi jõudlust kriitiliselt. Seetõttu peaksite kõigepealt mõistma oma süsteemis andmete salvestamise ja lugemise oodatavaid omadusi. Siis peate olema võimeline neid näitajaid hindama ja tegema valikud tuginedes tehtud hindamistele. Kuid te suudate seda tööd tõhusalt teha vaid siis, kui olete teadlik olemasolevatest andmestruktuuri mudelitest. Üldiselt tähendavad need kindlaid teadmisi, mis on seotud .
Andmebaase võib pidada andmestruktuurideks, millel on erakordne skaleeritavus ja püsivus. Seetõttu peaks andmestruktuuride tundmine olema kasulik ka teile, kui valite ühte või teist andmebaasi. Näiteks Redis on andmestruktuuride teenus, mis toetab erinevaid väärtuste tüüpe. See võimaldab töötada selliste andmestruktuuridega nagu loendid ja komplektid ning lugeda andmeid tuntud algoritmide kaudu, näiteks , korraldades seda tööd püsivas ja kõrge kättesaadavuse vormis.
Pilt Unsplashi saidilt
Kui olete piisavalt orienteeritud erinevates andmete salvestamise mustrites, liikuge edasi andmete järjepidevuse ja kättesaadavuse uurimise juurde. Esmalt peate omandama , vähemalt üldiselt, ja seejärel täiendama neid teadmisi, uurides lähemalt juurdunud mustreid ja . Nii saad te tunda valdkonna laiemat pilti ja mõista, et andmete lugemine ja kirjutamine on tegelikult kaks täiesti erinevat probleemi, igaühega on seotud oma spetsiifilised väljakutsed. Varustades end mitmete järjepidevuse ja kättesaadavuse tagamise mustritega, saate märkimisväärselt tõsta süsteemi tootlikkust, samal ajal tagades andmete sujuva kättesaadavuse teie rakendustes.
Lõpetades andmete salvestamise teemadel rääkimise, tuleb mainida ka vahemälu. Kas seda tuleks hallata samaaegselt kliendis ja serveris? Milliseid andmeid hoiate vahemälus? Ja miks? Kuidas organiseerite vahemälu tühjendamise? Kas see toimub regulaarselt, teatud ajavahemike järel? Kui jah, siis kui sageli? Nende teemadega soovitaksin alustada ülespool mainitud 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õrgu piires võivad olla privaatsed, aga teised peavad olema avalikud ja avatud väliskasutajatele, kes neile ligipääsu otsivad.
On oluline tagada nende ressursside omavaheline kommunikatsioon, samuti teabe vahetamine kogu süsteemi ja välismaailma vahel. Süsteemide projekteerimise kontekstis seisame siin jälle silmitsi uute ainulaadsete väljakutsetega. Uurime, kuidas võivad olla kasulikud , ja millised erinevad kommunikatsioonimustrid on saadaval.
Pilt Unsplashi saidilt
, mille tagamisele tuleb läheneda tõsiselt ja aktiivselt tegeleda selle teemaga. Ühenduste jaotamine
Ühenduste jaotamine
Ei ole kindel, et selle teema eraldi sektsiooniks välja toomine näib kõigile põhjendatud. Sellegipoolest selgitan siin seda kontseptsiooni põhjalikult, tuues välja, et selle osa materjali on kõige täpsem kirjeldada terminiga „ühenduste jaotamine“ (connection distribution).
Süsteemid kujunevad välja õige hulga komponentide ühendamise kaudu, ja nendevaheline kommunikatsioon toimub sageli kehtivate protokollide, näiteks TCP ja UDP alusel. Kuid enamasti pole neid protokolle piisavalt, et rahuldada kaasaegsete süsteemide kõiki vajadusi, mis sageli töötavad kõrge koormuse all ja sõltuvad suuresti kasutajate nõudmistest. Sageli on vajalik leida viise ühenduste jaotamiseks, et tulla toime selliste kõrgete koormustega süsteemis.
Selle jaotamise aluseks on hästi tuntud (DNS). Selline süsteem võimaldab muuta domeeninime, näiteks kaalutud ringdaanide algoritmi (weighted round robin) ja viivituste põhised meetodid, mis aitavad jaotada koormust.
on põhimõtteliselt 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 mitme saadaval oleva eksemplari vahel. Koormuse tasakaalustajad võivad olla nii riistvara kui ka tarkvara, kuid praktikas puutume sagedamini kokku tarkvaralistega, näiteks ja . on kontseptsioonilt samuti väga sarnased koormuse tasakaalustajatele, kuigi nende vahel on rida . Need erinevused tuleb tingimata arvesse võtta, kavandades süsteemi vastavalt oma vajadustele.
Samuti tuleb olla teadlik (CDN). CDN on globaalne jaotatud serverite võrk, mis edastab teavet nendest sõlmedest, mis asuvad geograafiliselt lähemal konkreetsele kasutajale. CDN-e on eelistatav kasutada, kui töötate staatiliste failidega, mis on kirjutatud JavaScriptis, CSS-is ja HTML-is. Lisaks on tänapäeval levinud sellised pilveteenused, mille kaudu pakutakse liikluse haldurit, näiteks , tagades teile globaalne levik ja vähenenud latentsus dünaamilise sisu kasutamisel. Siiski on sellised teenused tavaliselt kasulikud olukordades, kus tuleb töötada seisu säilitamata veebiteenustega.
Räägime äriloogikast. Äri loogika, ülesandeloome ja komponentide struktuurimine.
Nii oleme saanud arutada erinevaid süsteemi infrastruktuuri aspekte. Tõenäoliselt ei mõtle kasutaja isegi kõigile nendele teie süsteemi elementidele ja, ausalt öeldes, ei muretse nende pärast üldse. Kasutajat huvitab, kuidas on suhelda teie süsteemiga, mida on võimalik saavutada, kui tegutseda nii, ning kuidas süsteem täidab kasutaja käske, mida ja kuidas ta teeb kasutaja andmetega.
Kuidas selgesti pealkirjast selgub, plaanisin selles artiklis rääkida tarkvara arhitektuurist ja süsteemide projekteerimisest. Seetõttu ei kavatsenud ma kirjeldada tarkvarade projekteerimise mustreid, mis näitavad, kuidas luuakse tarkvarakomponente. Kuid mida rohkem ma sellest mõtlen, seda enam tundub mulle, et piir tarkvarade projekteerimise mustrite ja arhitektuuriliste mustrite vahel on väga hägune ja need kaks kontseptsiooni on tihedalt seotud. Võtame näiteks (event sourcing). Kui hakkate seda arhitektuurilist mustrit rakendama, mõjutab see praktiliselt kõiki teie süsteemi aspekte: andmete pikaajaline salvestamine, teie süsteemis kehtiv konsistentsitase, komponentide kontuurid jne. Seetõttu otsustasin mainida mõningaid arhitektuurilisi mustreid, mis on otseselt seotud äriloogikaga. Isegi kui selles artiklis tuleb piirduda lihtsa loendiga, soovitan teil tutvuda sellega ja mõelda ideedele, mis on seotud nende mustritega. Siin on, palun:
- Kontseptsioonid , eriti ,
Koostöö lähenemisviisid
On tõenäoliselt väga vähe tõenäoline, et te olete projektis see osaleja, kes üksi vastutab süsteemi projekteerimise protsessi eest. Vastupidi, tõenäoliselt peate te suhtlema kolleegidega, kes töötavad nii teie ülesande raames kui ka väljaspool seda. Sel juhul võib osutuda vajalikuks hinnata valitud tehnoloogilisi lahendusi koos kolleegidega, eristada ärilisi vajadusi ja mõista, kuidas ülesandeid paremini paralleelselt täita.
Pilt Unsplashi saidilt
Esiteks on vajalik välja töötada täpne ja üldiselt tunnustatud arusaam, milline on see ärieesmärk, mida te üritate saavutada, ja milliste muutuvate elementidega te peate tegelema. Rühmamudeldamise tehnikad, sealhulgas (event storming), aitavad seda protsessi oluliselt kiirendada ja suurendavad teie eduvõimalusi. Selle uurimisega saab tegeleda enne või pärast seda, kui olete määratlenud , ja seejärel süvendada seda toote küpsemise ajal. Tuginenud sellele ühtse arusaamade tasemele, mida siin saavutatakse, saate ka sõnastada selle piiratud konteksti jaoks, milles te töötate. Kui on vaja rääkida teie süsteemi arhitektuurist, võib teile kasulikuks osutuda , mille pakkus välja , eriti kui on vaja mõista, kui palju peate problemaatika detailidesse süvenema, visualiseerides asju, mida soovite edastada.
Tõenäoliselt leidub sellel teemal ka teisi küpseid tehnoloogiaid, mis on sama kasulikud kui ainepõhine disain. Siiski, me naaseme, olgu kuidas on, aineala mõistmise juurde, seetõttu reaalne teadmine ja kogemus peaks teile kasuks tulema.
Allikas: habr.com
