Tere kolleegid.
Täna pakume teile kaalumiseks Tugberk Ugurlu artikli tõlget, kes võttis suhteliselt väikeses mahus välja kaasaegsete tarkvarasüsteemide kujundamise põhimõtted. Siin on see, mida autor enda kohta kokkuvõttes ütleb:
Kuna habro artiklis on täiesti võimatu kajastada nii kolossaalset teemat nagu arhitektuurimustrid + kujundusmustrid 2019. aasta seisuga, siis soovitame mitte ainult härra Uruglu enda teksti, vaid ka arvukaid linke, mille ta sinna lahkesti lisas. Kui teile meeldib, avaldame hajutatud süsteemide disaini kohta üksikasjalikuma teksti.
Ülevaade rakendusest Unsplash
Kui te pole kunagi pidanud silmitsi seisma selliste väljakutsetega nagu tarkvarasüsteemi nullist kujundamine, siis sellist tööd alustades pole mõnikord isegi selge, kust alustada. Usun, et kõigepealt peate tõmbama piirid, et teil oleks enam-vähem kindel ettekujutus, mida täpselt kavatsete kujundada, ja seejärel käärida käised üles ja töötada nende piiride sees. Alustuseks võite võtta toote või teenuse (ideaaljuhul sellise, mis teile väga meeldib) ja mõelda, kuidas seda rakendada. Võite olla üllatunud, kui lihtne see toode välja näeb ja kui palju keerukust see tegelikult sisaldab. Ära unusta: , ja see on okei.
Ma arvan, et parim nõuanne, mida saan anda kõigile, kes hakkavad süsteemi kavandama, on järgmine: ärge tehke mingeid oletusi! Kohe alguses peate täpsustama selle süsteemi kohta teadaolevaid fakte ja sellega seotud ootusi. Siin on mõned head küsimused, mis aitavad teil disainiga alustada:
- Mis on probleem, mida me lahendada püüame?
- Kui suur on meie süsteemiga suhtlevate kasutajate maksimaalne arv?
- Milliseid andmete kirjutamise ja lugemise mustreid me kasutame?
- Millised on eeldatavad ebaõnnestumise juhtumid, kuidas me neid käsitleme?
- Millised on ootused süsteemi järjepidevusele ja kättesaadavusele?
- Kas töötamisel tuleb arvestada välise kontrollimise ja reguleerimisega seotud nõuetega?
- Mis tüüpi tundlikke andmeid me talletame?
Need on vaid mõned küsimused, mis on olnud kasulikud nii mulle kui ka meeskondadele, milles olen aastatepikkuse professionaalse tegevuse jooksul osalenud. Kui teate vastuseid neile küsimustele (ja kõigile teistele, mis on asjakohased kontekstis, milles peate töötama), saate järk-järgult süveneda probleemi tehnilistesse üksikasjadesse.
Määrake algtase
Mida ma siin "algtaseme" all mõtlen? Tegelikult saab tänapäeval enamikku tarkvaratööstuse probleeme olemasolevate meetodite ja tehnoloogiate abil lahendada. Sellest tulenevalt saate sellel maastikul navigeerides teatud edumaa, kui seisate silmitsi probleemidega, mille keegi teine pidi enne teid lahendama. Ärge unustage, et programmid on kirjutatud äri- ja kasutajaprobleemide lahendamiseks, seega püüame probleemi lahendada kõige arusaadavamal ja lihtsamal (kasutaja seisukohast) viisil. Miks on seda oluline meeles pidada? Võib-olla meeldib teile oma koordinaatsüsteemis otsida ainulaadseid lahendusi kõikidele probleemidele, sest arvate, et "mis programmeerija ma olen, kui järgin igal pool mustreid"? Tegelikult, siinne kunst teeb otsuseid selle kohta, kus ja mida teha. Loomulikult peab igaüks meist aeg-ajalt tegelema ainulaadsete probleemidega, millest igaüks on tõeline väljakutse. Kui aga meie esialgne tase on selgelt piiritletud, siis teame, millele oma energiat kulutada: kas meie ees seisva probleemi lahendamiseks valmis variantide otsimiseks või selle edasiseks uurimiseks ja sügavama arusaamise saamiseks.
Arvan, et suutsin teid veenda, et kui spetsialist saab enesekindlalt aru, mis on mõne imelise tarkvarasüsteemi arhitektuurne komponent, siis on need teadmised arhitekti kunsti valdamiseks ja selles valdkonnas kindla aluse loomiseks hädavajalikud.
Olgu, kust alustada? U GitHubis on hoidla nimega , kust saate õppida suuremahuliste süsteemide kavandamist, samuti valmistuda selleteemalisteks intervjuudeks. Hoidlas on näidetega jaotis , kus mõeldakse eelkõige sellele, kuidas nad oma süsteemide disainile lähenevad nt Twitter, Uber jne.
Kuid enne selle materjali juurde asumist vaatame lähemalt kõige olulisematest arhitektuurilistest väljakutsetest, millega praktikas silmitsi seisame. See on oluline, sest tõrksa ja mitmetahulise probleemi puhul tuleb PALJU tahke täpsustada ning seejärel antud süsteemis kehtivate regulatsioonide raames lahendada. , endine Facebooki töötaja, kirjutas , kus ta jagas oma kogemust sadade taotlejate sõelumisel. Kuigi video keskendub suuresti suure süsteemi disainile ja edukriteeriumidele, mis on sellisele ametikohale kandidaadi otsimisel olulised, on see siiski põhjalik allikas selle kohta, millised asjad on süsteemide kujundamisel kõige olulisemad. Soovitan ka see video.
Koguge teadmisi andmete salvestamise ja hankimise kohta
Tavaliselt mõjutab teie otsus selle kohta, kuidas andmeid pikaajaliselt salvestate ja hankite, süsteemi jõudlust kriitiliselt. Seetõttu peate esmalt mõistma oma süsteemi eeldatavaid kirjutamis- ja lugemisomadusi. Siis tuleb osata neid näitajaid hinnata ja tehtud hinnangute põhjal teha valikuid. Kuid saate selle tööga tõhusalt toime tulla ainult siis, kui mõistate olemasolevaid andmesalvestusmustreid. Põhimõtteliselt tähendab see kindlaid teadmisi, mis on seotud .
Andmebaase võib pidada andmestruktuurideks, mis on äärmiselt skaleeritavad ja vastupidavad. Seetõttu peaksid teadmised andmestruktuuride kohta olema teile konkreetse andmebaasi valimisel väga kasulikud. Näiteks, on andmestruktuuri server, mis toetab erinevat tüüpi väärtusi. See võimaldab teil töötada andmestruktuuridega, nagu loendid ja komplektid, ning lugeda andmeid, kasutades näiteks tuntud algoritme, , korraldades sellist tööd vastupidavas ja hästi ligipääsetavas stiilis.
Ülevaade rakendusest Unsplash
Kui olete erinevatest andmesalvestusmustritest piisavalt aru saanud, jätkake andmete järjepidevuse ja kättesaadavuse uurimisega. Kõigepealt peate mõistma vähemalt üldises plaanis ja seejärel lihvige neid teadmisi väljakujunenud mustritega lähemalt tutvudes и . Nii arendate valdkonna mõistmist ja mõistate, et andmete lugemine ja kirjutamine on tegelikult kaks väga erinevat probleemi, millest igaühel on oma ainulaadsed väljakutsed. Mõne järjepidevuse ja kättesaadavuse mustriga relvastatud saate oluliselt suurendada süsteemi jõudlust, tagades samal ajal sujuva andmevoo oma rakendustesse.
Lõpetuseks peaksime andmesalvestusprobleemide teemalise vestluse lõpetuseks mainima ka vahemälu. Kas see peaks töötama kliendis ja serveris samaaegselt? Millised andmed on teie vahemälus? Ja miks? Kuidas korraldate vahemälu kehtetuks tunnistamist? Kas seda tehakse regulaarselt, teatud ajavahemike järel? Kui jah, siis kui tihti? Soovitan alustada nende teemade uurimist eelmainitud süsteemi disaini krunt.
Suhtlusmustrid
Süsteemid koosnevad erinevatest komponentidest; need võivad olla erinevad protsessid, mis töötavad samas füüsilises sõlmes, või erinevad masinad, mis töötavad teie võrgu erinevates osades. Mõned neist teie võrgus olevatest ressurssidest võivad olla privaatsed, kuid teised peaksid olema avalikud ja avatud neile väljastpoolt juurde pääsevatele tarbijatele.
Tuleb tagada nende ressursside omavaheline suhtlus, samuti infovahetus kogu süsteemi ja välismaailma vahel. Süsteemide kujundamise kontekstis seisame taas silmitsi uute ja ainulaadsete väljakutsetega. Vaatame, kuidas need võivad olla kasulikud , ja mida lk.
Ülevaade rakendusest Unsplash
Välismaailmaga suhtlemise korraldamisel on see alati väga oluline , mille pakkumisse tuleb samuti tõsiselt suhtuda ja sellega aktiivselt tegeleda.
Ühenduse jaotus
Ma pole kindel, et selle teema eraldi sektsiooni panemine tundub kõigile õigustatud. Sellegipoolest esitan selle kontseptsiooni siin üksikasjalikult ja usun, et selle jaotise materjali kirjeldab kõige täpsemalt mõiste "ühenduse jaotus".
Süsteemid moodustatakse paljude komponentide õigel ühendamisel ning nende omavaheline suhtlus on sageli korraldatud kehtestatud protokollide alusel, näiteks TCP ja UDP. Kuid need protokollid kui sellised ei ole sageli piisavad, et rahuldada kõiki tänapäevaste süsteemide vajadusi, mis töötavad sageli suure koormuse all ja sõltuvad suuresti ka kasutajate vajadustest. Sageli on vaja leida viise ühenduste levitamiseks, et tulla toime nii suure süsteemi koormusega.
See jaotus põhineb üldtuntud (DNS). Selline süsteem võimaldab koormuse jaotamiseks domeeninimede teisendusi, näiteks kaalutud ümmarguse analüüsi ja latentsuspõhiseid meetodeid.
on põhimõtteliselt oluline ja peaaegu kõik suured Interneti-süsteemid, millega täna tegeleme, asuvad ühe või mitme koormuse tasakaalustaja taga. Koormuse tasakaalustajad aitavad jaotada klientide päringuid mitme saadaoleva eksemplari vahel. Koormuse tasakaalustajaid on nii riist- kui tarkvaras, praktikas tuleb aga sagedamini kokku puutuda näiteks tarkvaralistega и . kontseptuaalselt ka väga sarnane koormuse tasakaalustajatele, kuigi esimese ja teise vahel on vahemik . Neid erinevusi tuleb oma vajadustest lähtuva süsteemi kavandamisel arvestada.
Samuti peaksite teadma (CDN). CDN on ülemaailmne hajutatud puhverserverite võrk, mis edastab teavet sõlmedest, mis asuvad geograafiliselt konkreetsele kasutajale lähemal. Kui töötate JavaScriptis, CSS-is ja HTML-is kirjutatud staatiliste failidega, on soovitatav kasutada CDN-e. Lisaks on tänapäeval levinud liikluskorraldajaid pakkuvad pilveteenused, näiteks , mis pakub dünaamilise sisuga töötamisel ülemaailmset levitamist ja väiksema latentsusaega. Kuid sellised teenused on tavaliselt kasulikud juhtudel, kui peate töötama kodakondsuseta veebiteenustega.
Räägime äriloogikast. Äriloogika, ülesannete voogude ja komponentide struktureerimine
Seega õnnestus meil arutada süsteemi erinevaid infrastruktuuri aspekte. Tõenäoliselt ei mõtle kasutaja isegi kõigi nende süsteemi elementide peale ja ausalt öeldes ei hooli neist üldse. Kasutajat huvitab, kuidas on teie süsteemiga suhelda, mida sellega saavutada on võimalik ning kuidas süsteem kasutaja käske täidab, mida ja kuidas kasutajaandmetega teeb.
Nagu selle artikli pealkiri viitab, kavatsesin ma rääkida tarkvara arhitektuurist ja süsteemikujundusest. Sellest lähtuvalt ei plaaninud ma käsitleda tarkvara disaini mustreid, mis kirjeldavad tarkvarakomponentide loomist. Mida rohkem ma aga sellele mõtlen, seda enam tundub mulle, et piir tarkvarakujundusmustrite ja arhitektuurimustrite vahel on väga hägune ning need kaks mõistet on omavahel tihedalt seotud. Võtame näiteks (ürituste hankimine). Kui olete selle arhitektuurse mustri omaks võtnud, mõjutab see peaaegu kõiki teie süsteemi aspekte: andmete pikaajaline salvestamine, teie süsteemi järjepidevuse tase, selles olevate komponentide kuju jne jne. Seetõttu otsustasin mainida mõningaid arhitektuurilisi mustreid, mis on otseselt seotud äriloogikaga. Kuigi see artikkel peab piirduma lihtsa loendiga, soovitan teil sellega tutvuda ja mõelda nende mustritega seotud ideedele. Siin sa oled:
- Mõisted , eriti, ,
Koostööl põhinevad lähenemisviisid
On äärmiselt ebatõenäoline, et leiate end projektist osalejana, kes vastutab ainuisikuliselt süsteemi kujundamise protsessi eest. Vastupidi, peate suure tõenäosusega suhtlema kolleegidega, kes töötavad nii teie ülesande raames kui ka väljaspool seda. Sel juhul peate võib-olla hindama valitud tehnoloogilisi lahendusi koos kolleegidega, tuvastama ärivajadused ja mõistma, kuidas ülesandeid kõige paremini paralleelstada.
Ülevaade rakendusest Unsplash
Esimene samm on kujundada täpne ja jagatud arusaam sellest, mis on teie ärieesmärk, mida üritate saavutada ja milliste liikuvate osadega peate tegelema. Eelkõige rühma modelleerimise tehnikad (sündmustorm) aitavad seda protsessi oluliselt kiirendada ja tõstavad eduvõimalusi. Seda tööd saab teha enne või pärast visandamist ja seejärel süvendage seda toote küpsedes. Siin saavutatava järjepidevuse taseme põhjal saate ka sõnastada piiratud kontekstis, milles töötate. Kui teil on vaja rääkida oma süsteemi arhitektuurist, võib see teile kasulikuks osutuda , pakutud , eriti kui peate mõistma, kui palju peate probleemi üksikasjadesse süvenema, visualiseerides asju, mida soovite suhelda.
Tõenäoliselt on sellel teemal veel üks arenenud tehnoloogia, mis pole vähem kasulik kui domeenipõhine disain. Küll aga jõuame kuidagi tagasi ainevaldkonna mõistmiseni, seega valdkonna teadmised ja kogemused peaks teile kasulik olema.
Allikas: www.habr.com