Hej kolleger.
I dag tilbyder vi til din overvejelse en oversættelse af en artikel af Tugberk Ugurlu, som påtog sig at skitsere i et relativt lille volumen principperne for design af moderne softwaresystemer. Her er hvad forfatteren siger om sig selv i opsummering:
Da det er absolut umuligt i en habro-artikel at dække et så kolossalt emne som arkitektoniske mønstre + designmønstre fra 2019, anbefaler vi ikke kun teksten fra hr. Uruglu selv, men også de talrige links, som han venligst inkluderede i den. Hvis du kan lide det, udgiver vi en mere højt specialiseret tekst om design af distribuerede systemer.
øjebliksbillede fra Unsplash
Hvis du aldrig har skullet stå over for sådanne udfordringer som at designe et softwaresystem fra bunden, så er det nogle gange ikke engang klart, hvor du skal starte, når du starter et sådant arbejde. Jeg tror på, at du først skal trække grænser, så du har en mere eller mindre sikker idé om, hvad du præcist skal designe, og derefter smøge ærmerne op og arbejde inden for disse grænser. Som udgangspunkt kan du tage et produkt eller en tjeneste (ideelt set en, du virkelig kan lide) og finde ud af, hvordan du implementerer det. Du kan blive overrasket over, hvor enkelt dette produkt ser ud, og hvor meget kompleksitet det faktisk indeholder. Glem ikke: , og det er okay.
Jeg tror, at det bedste råd, jeg kan give til enhver, der begynder at designe et system, er dette: lav ikke nogen antagelser! Helt fra begyndelsen skal du specificere de kendte fakta om dette system og forventningerne forbundet med det. Her er nogle gode spørgsmål at stille for at hjælpe dig i gang med dit design:
- Hvad er det problem, vi forsøger at løse?
- Hvad er det højeste antal brugere, der vil interagere med vores system?
- Hvilke mønstre for at skrive og læse data vil vi bruge?
- Hvad er de forventede fejlsager, hvordan skal vi håndtere dem?
- Hvad er forventningerne til systemkonsistens og tilgængelighed?
- Skal du tage højde for eventuelle krav relateret til ekstern verifikation og regulering, når du arbejder?
- Hvilke typer følsomme data skal vi gemme?
Dette er blot nogle få spørgsmål, som har været nyttige for både mig og de teams, som jeg har deltaget i gennem årene med professionel aktivitet. Hvis du kender svarene på disse spørgsmål (og andre, der er relevante for den kontekst, du skal arbejde i), så kan du gradvist dykke ned i de tekniske detaljer om problemet.
Indstil det indledende niveau
Hvad mener jeg med "baseline" her? Faktisk, i vores tid, "kan" de fleste problemer i softwareindustrien løses ved hjælp af eksisterende metoder og teknologier. Ved at navigere i dette landskab får du derfor et vist forspring, når du står over for problemer, som en anden skulle løse før dig. Glem ikke, at programmer er skrevet til at løse forretnings- og brugerproblemer, så vi bestræber os på at løse problemet på den mest ligetil og enkle (fra brugerens synspunkt) måde. Hvorfor er dette vigtigt at huske? Måske i dit koordinatsystem kan du godt lide at lede efter unikke løsninger til alle problemer, fordi du tænker, "hvad er jeg for en programmør, hvis jeg følger mønstre overalt"? Faktisk, kunsten her er at træffe beslutninger om, hvor og hvad de skal gøre. Selvfølgelig skal hver af os fra tid til anden håndtere unikke problemer, som hver især er en reel udfordring. Men hvis vores begyndelsesniveau er klart defineret, så ved vi, hvad vi skal bruge vores energi på: at søge efter færdige muligheder for at løse det stillede problem, eller studere det yderligere og få en dybere forståelse.
Jeg tror, jeg var i stand til at overbevise dig om, at hvis en specialist med sikkerhed forstår, hvad den arkitektoniske komponent i nogle vidunderlige softwaresystemer er, så vil denne viden være uundværlig for at mestre en arkitekts kunst og udvikle et solidt grundlag på dette område.
Okay, så hvor skal man begynde? U Der er et repository på GitHub kaldet , hvorfra du kan lære at designe store systemer, samt forberede dig til interviews om dette emne. Depotet har et afsnit med eksempler , hvor det især overvejes, hvordan de griber designet af deres systemer an fx Twitter, Uber osv.
Men før vi går videre til dette materiale, lad os se nærmere på de vigtigste arkitektoniske udfordringer, som vi står over for i praksis. Det er vigtigt, fordi man skal specificere MANGE aspekter af et genstridigt og mangefacetteret problem, og så løse det inden for rammerne af de gældende regler i et givent system. , skrev en tidligere Facebook-medarbejder , hvor han delte sin egen erfaring med at screene hundredvis af ansøgere. Mens videoen fokuserer meget på design af store systemer og de succeskriterier, der er vigtige, når man leder efter en kandidat til en sådan stilling, vil den stadig tjene som en omfattende ressource på, hvilke ting der er vigtigst, når man designer systemer. Jeg foreslår også denne video.
Opbyg viden om lagring og genfinding af data
Typisk har din beslutning om, hvordan du opbevarer og henter dine data på lang sigt, en kritisk indvirkning på systemets ydeevne. Derfor skal du først forstå de forventede skrive- og læseegenskaber for dit system. Så skal du kunne vurdere disse indikatorer og træffe valg ud fra de vurderinger, der er foretaget. Du kan dog kun effektivt klare dette arbejde, hvis du forstår eksisterende datalagringsmønstre. Dette indebærer i princippet solid viden ift .
Databaser kan opfattes som datastrukturer, der er ekstremt skalerbare og holdbare. Derfor bør viden om datastrukturer være meget nyttig for dig, når du skal vælge en bestemt database. For eksempel, er en datastrukturserver, der understøtter forskellige typer værdier. Det giver dig mulighed for at arbejde med datastrukturer såsom lister og sæt og læse data ved hjælp af velkendte algoritmer, f.eks. , organisere sådant arbejde i en holdbar og meget tilgængelig stil.
øjebliksbillede fra Unsplash
Når du har en tilstrækkelig forståelse af de forskellige datalagringsmønstre, skal du gå videre til at studere datakonsistens og tilgængelighed. Først og fremmest skal du forstå i hvert fald i generelle vendinger, og så pudse denne viden ved at se nærmere på etablerede mønstre и . På denne måde vil du udvikle en forståelse af feltet og forstå, at læsning og skrivning af data faktisk er to meget forskellige problemer, hver med sine egne unikke udfordringer. Bevæbnet med nogle få konsistens- og tilgængelighedsmønstre kan du øge systemets ydeevne betydeligt, samtidig med at du sikrer et jævnt dataflow til dine applikationer.
Til sidst, som afslutning på samtalen om datalagringsproblemer, bør vi også nævne caching. Skal det køre samtidigt på klienten og serveren? Hvilke data vil være i din cache? Og hvorfor? Hvordan organiserer du cache-invalidering? Vil det blive gjort regelmæssigt med bestemte intervaller? Hvis ja, hvor ofte? Jeg anbefaler at begynde at studere disse emner med den førnævnte systemdesignprimer.
Kommunikationsmønstre
Systemer består af forskellige komponenter; disse kan være forskellige processer, der kører inden for den samme fysiske node, eller forskellige maskiner, der kører på forskellige dele af dit netværk. Nogle af disse ressourcer i dit netværk kan være private, men andre bør være offentlige og åbne for forbrugere, der får adgang til dem udefra.
Det er nødvendigt at sikre kommunikation af disse ressourcer med hinanden, samt udveksling af information mellem hele systemet og omverdenen. I forbindelse med systemdesign står vi igen her over for en række nye og unikke udfordringer. Lad os se, hvordan de kan være nyttige , og hvad s.
øjebliksbillede fra Unsplash
Når man tilrettelægger kommunikationen med omverdenen, er det altid meget vigtigt , hvis levering også skal tages alvorligt og aktivt forfølges.
Forbindelsesfordeling
Jeg er ikke sikker på, at det vil virke berettiget for alle at sætte dette emne ind i et separat afsnit. Ikke desto mindre vil jeg præsentere dette koncept i detaljer her, og jeg mener, at materialet i dette afsnit er mest præcist beskrevet med begrebet "forbindelsesdistribution".
Systemer dannes ved korrekt at forbinde mange komponenter, og deres kommunikation med hinanden er ofte organiseret på grundlag af etablerede protokoller, for eksempel TCP og UDP. Imidlertid er disse protokoller som sådan ofte utilstrækkelige til at opfylde alle behovene i moderne systemer, som ofte drives under høj belastning og også er meget afhængige af brugernes behov. Det er ofte nødvendigt at finde måder at fordele forbindelser på for at klare så høje belastninger på systemet.
Denne fordeling er baseret på det velkendte (DNS). Et sådant system tillader domænenavnstransformationer såsom vægtet round robin og latency-baserede metoder til at hjælpe med at fordele belastningen.
er grundlæggende vigtigt, og næsten alle store internetsystemer, vi beskæftiger os med i dag, er placeret bag en eller flere load balancers. Load balancers hjælper med at distribuere klientanmodninger på tværs af flere tilgængelige forekomster. Load balancers findes i både hardware og software, men i praksis skal man oftere beskæftige sig med software, f.eks. и . konceptuelt også meget lig load balancers, selvom der er et interval mellem den første og den anden . Disse forskelle skal tages i betragtning, når man designer et system baseret på dine behov.
Du bør også vide om (CDN). Et CDN er et globalt distribueret netværk af proxy-servere, der leverer information fra noder, der er geografisk placeret tættere på en bestemt bruger. CDN'er er at foretrække at bruge, hvis du arbejder med statiske filer skrevet i JavaScript, CSS og HTML. Derudover er cloud-tjenester, der leverer trafikledere, almindelige i dag, f.eks. , hvilket giver dig global distribution og reduceret ventetid, når du arbejder med dynamisk indhold. Sådanne tjenester er dog normalt nyttige i tilfælde, hvor du skal arbejde med statsløse webtjenester.
Lad os tale om forretningslogik. Strukturering af forretningslogik, opgaveflow og komponenter
Så det lykkedes os at diskutere forskellige infrastrukturelle aspekter af systemet. Mest sandsynligt tænker brugeren ikke engang på alle disse elementer i dit system og er helt ærligt ligeglad med dem overhovedet. Brugeren er interesseret i, hvordan det er at interagere med dit system, hvad der kan opnås ved at gøre dette, og også hvordan systemet udfører brugerkommandoer, hvad og hvordan det gør med brugerdata.
Som titlen på denne artikel antyder, skulle jeg tale om softwarearkitektur og systemdesign. Derfor havde jeg ikke planer om at dække softwaredesignmønstre, der beskriver, hvordan softwarekomponenter skabes. Men jo mere jeg tænker over det, jo mere forekommer det mig, at grænsen mellem softwaredesignmønstre og arkitektoniske mønstre er meget sløret, og de to begreber er tæt beslægtede. Lad os tage for eksempel (begivenhedssourcing). Når du først har vedtaget dette arkitektoniske mønster, vil det påvirke næsten alle aspekter af dit system: langtidslagring af data, niveauet af konsistens i dit system, formen på komponenterne i det osv. osv. Derfor besluttede jeg at nævne nogle arkitektoniske mønstre, der direkte relaterer til forretningslogik. Selvom denne artikel bliver nødt til at begrænse sig til en simpel liste, opfordrer jeg dig til at sætte dig ind i den og tænke over de ideer, der er forbundet med disse mønstre. Her er du:
- koncept , i særdeleshed, ,
Samarbejdstilgange
Det er yderst usandsynligt, at du vil finde dig selv på et projekt som den deltager, der alene er ansvarlig for systemdesignprocessen. Tværtimod vil du højst sandsynligt skulle interagere med kolleger, der arbejder både inden for og uden for din opgave. I dette tilfælde skal du muligvis evaluere de valgte teknologiløsninger sammen med kolleger, identificere forretningsbehov og forstå, hvordan du bedst paralleliserer opgaver.
øjebliksbillede fra Unsplash
Det første skridt er at udvikle en nøjagtig og fælles forståelse af, hvad det forretningsmål, du forsøger at opnå, er, og hvilke bevægelige dele, du skal håndtere. Gruppemodelleringsteknikker, især (event storming) er med til at fremskynde denne proces betydeligt og øge dine chancer for succes. Dette arbejde kan udføres før eller efter du skitserer , og derefter uddybe det, efterhånden som produktet modnes. Ud fra det niveau af konsistens, der vil blive opnået her, kan du også formulere for den begrænsede kontekst, du arbejder i. Når du har brug for at tale om arkitekturen i dit system, kan du finde det nyttigt , foreslog , især når du har brug for at forstå, hvor meget du bliver nødt til at gå ind i detaljerne i problemet, visualisere de ting, du vil kommunikere.
Der er sandsynligvis en anden moden teknologi om dette emne, der ikke er mindre nyttig end Domain Driven Design. Vi vender dog på en eller anden måde tilbage til at forstå fagområdet, så viden og erfaring på området burde være nyttig for dig.
Kilde: www.habr.com