Hej kolleger.
I dag præsenteres der en oversættelse af artiklen af Tugberk Ugurlu, som på en relativt kortfattet måde forsøger at beskrive principperne for design af moderne softwaresystemer. Her er hvad forfatteren fortæller om sig selv i kort form:
Da det er umuligt at dække et så kolossalt emne som arkitekturmønstre + designmønstre pr. 2019 i en hub-statistik, anbefaler vi ikke kun selve teksten af hr. Ugurlu, men også de mange links, han venligt har tilføjet. Hvis du kan lide det, vil vi også publicere en mere specialiseret tekst om design af distribuerede systemer.
Billede fra Unsplash
Hvis du aldrig har stået over for udfordringer som at designe et softwaresystem fra bunden, kan det fra starten være svært at vide, hvor man skal begynde. Jeg mener, det første skridt er at afgrænse rammerne, så du har en rimelig idé om, hvad du skal designe, derefter - op med ærmerne og arbejde inden for disse rammer. Et godt udgangspunkt kan være et produkt eller en service (ideelt set noget, du virkelig kan lide) og sætte dig ind i, hvordan det er implementeret. Du vil måske blive overrasket over, hvor enkelt dette produkt ser ud, og hvilken enorm kompleksitet der faktisk er gemt i det. Husk: , og det er helt normalt.
Jeg tror, det bedste råd, jeg kan give til dem, der begynder at designe et system, er: lad ikke formodninger styre! Fra starten skal du præcisere de fakta, der er kendt om dette system, og tilhørende forventninger. Her er nogle gode spørgsmål, hvis svar vil hjælpe dig med at komme i gang med designet:
- Hvad er problemet, vi forsøger at løse?
- Hvor mange brugere vil interagere med vores system på spidsen?
- Hvilke mønstre for databeregning og -læsnings vil vi anvende?
- Hvad er de forventede fejlscenarier, og hvordan planlægger vi at håndtere dem?
- Hvilke forventninger er der til systemets konsistens og tilgængelighed?
- Skal man tage højde for nogen krav i forbindelse med ekstern kontrol og regulering i sit arbejde?
- Hvilke typer af fortrolige data har vi tænkt os at opbevare?
Det er kun et par spørgsmål, der har været nyttige både for mig og de teams, jeg har haft fornøjelsen af at arbejde med gennem min professionelle karriere. Hvis du kender svarene på disse spørgsmål (og på eventuelle andre, der er relevante i den kontekst, hvor du arbejder), kan man gradvist dykke ned i de tekniske detaljer af opgaven.
Fastlægger det grundlæggende niveau
Hvad mener jeg her med «grundlæggende niveau»? I vores tid kan de fleste problemer i softwareindustrien «løses» ved hjælp af de metoder og teknologier, der allerede findes. Derfor, når man orienterer sig i dette landskab, får man en bestemt fordel, når man står over for opgaver, som andre har løst før en selv. Lad os ikke glemme, at programmer skrives for at løse forretnings- og brugerproblemer, derfor stræber vi efter at løse opgaverne på den mest straightforward og enkle måde (set fra brugerens perspektiv). Hvorfor er det vigtigt at huske? Måske kan du i dit koordinatsystem lide at finde unikke løsninger til alle opgaver, fordi du mener, «hvordan kan jeg kalde mig selv en programmør, hvis jeg altid følger mønstre»? I virkeligheden ligger kunsten her i at træffe beslutninger om, hvor og hvad man skal gøre. Selvfølgelig står vi alle engang imellem over for unikke problemer, som hver især er en rigtig udfordring. Men hvis vores grundlæggende niveau er klart afgrænset, ved vi, hvor vi skal lægge vores kræfter: i at finde eksisterende løsningsmuligheder for den opgave, der er præsenteret for os, eller i at dykke dybere ind i dens studium og forståelse.
Jeg tror, jeg har overbevist dig om, at hvis en specialist er fortrolig med den arkitektoniske opbygning af nogle bemærkelsesværdige softwaresystemer, vil denne viden være uvurderlig for at mestre kunstnerens håndværk og opbygge et solidt fundament inden for området.
Okay, så hvor skal man starte? U har et repository på GitHub ved navn , hvorfra du kan lære at designe store systemer og forberede dig til interviews om emnet. I opslaget er der en sektion med eksempler , hvoraf nogle kendte virksomheder analyseres med hensyn til, hvordan de designer deres systemer , såsom Twitter, Uber osv.
Men før vi dykker ned i dette materiale, lad os tage et kig på de mest kritiske arkitekturudfordringer, man ofte møder i praksis. Dette er vigtigt, da man skal specificere et NOGET antal aspekter af det komplekse og mangefacetterede problem og derefter løse det inden for rammerne af de gældende reguleringer i det pågældende system. , en tidligere Facebook-ansat, har lavet , hvor han delte sin egen erfaring med at vurdere hundredvis af ansøgere. Selvom videoen specifikt handler om design af store systemer og de succesfaktorer, der er vigtige, når man søger kandidater til sådanne stillinger, vil den også være en omfattende ressource om, hvilke aspekter der er mest afgørende i systems design. Jeg tilbyder også af denne video.
Opbyg viden om datalagring og -udtræk
Generelt påvirker din beslutning om, hvordan du vil lagre og udgive dine data på lang sigt, systemets ydeevne kritisk. Derfor skal du først og fremmest forstå de forventede skrivning- og læseegenskaber i dit system. Derefter skal du kunne vurdere disse indikatorer og træffe valg baseret på disse vurderinger. Men for effektivt at tackle denne opgave skal du kunne navigere i eksisterende datalagringsmønstre. Dette indebærer i princippet solid viden relateret til .
Databaser kan betragtes som datakonstruktioner, der udviser fremragende skalerbarhed og holdbarhed. Derfor vil viden om datakonstruktioner komme dig til gode, når du skal vælge en bestemt database. For eksempel, – det er en datakilde, der understøtter forskellige typer værdier. Den giver mulighed for at arbejde med sådanne datagrænseflader som lister og mængder, samt at læse data ved hjælp af kendte algoritmer, som f.eks. , og organiserer dette arbejde på en holdbar og højtilgængelig måde.
Billede fra Unsplash
Når du har fået en tilstrækkelig forståelse af forskellige datalagringsmønstre, kan du gå videre til at studere konsistens og tilgængelighed af data. Først skal du lære om i det mindste i grove træk, og derefter forfine denne viden ved nærmere at undersøge etablerede mønstre for og . På denne måde vil du opbygge et perspektiv inden for dette område og forstå, at læsning og skrivning af data reelt er to meget forskellige problemer, og hver af dem har sine egne særlige udfordringer. Udstyret med et par mønstre for at sikre konsistens og tilgængelighed, vil du kunne øge systemets ydeevne betydeligt, samtidig med at du sikrer en uafbrudt levering af data til dine applikationer.
Endelig, når vi slutter vores diskussion om datalagring, skal vi også nævne caching. Skal det foregå simultant på klienten og serveren? Hvilke data vil du have i din cache? Og hvorfor? Hvordan organiserer du cache-invalidering? Vil det blive udført regelmæssigt, med bestemte intervaller? Hvis ja – hvor ofte? Jeg anbefaler at begynde at arbejde med disse emner fra den førnævnte lærebog om systemdesign.
Kommunikationsmønstre
Systemer består af forskellige komponenter; det kan være både forskellige processer, der kører inden for den samme fysiske node, og forskellige maskiner, der opererer i forskellige dele af dit netværk. Nogle af disse ressourcer inden for dit netværk kan være private, men andre skal være offentlige og åbne for forbrugere, der henvender sig til dem udefra.
Det er nødvendigt at sikre kommunikation mellem disse ressourcer indbyrdes, samt at udveksle information mellem hele systemet og den ydre verden. I sammenhæng med systemdesign støder vi igen på en række nye unikke udfordringer. Lad os undersøge, hvordan , og hvilke r.
Billede fra Unsplash
Når man organiserer kommunikation med omverdenen, er det altid meget vigtigt , og man skal også tage dette alvorligt og engagere sig aktivt i det.
fordelingen af forbindelser
Jeg er ikke sikker på, at det ville virke berettiget at fremhæve dette emne som en selvstændig sektion. Ikke desto mindre vil jeg her udførligt beskrive dette koncept, idet jeg mener, at materialet i denne sektion bedst beskrives ved termen „fordeling af forbindelser“ (connection distribution).
Systemer dannes ved korrekt at forbinde mange komponenter, og deres kommunikation imellem organiseres ofte på basis af etablerede protokoller, såsom TCP og UDP. Imidlertid er disse protokoller som sådan ofte utilstrækkelige til at opfylde alle moderne systemers behov, som ofte driver under høj belastning og også i høj grad afhænger af brugernes behov. Det er ofte nødvendigt at finde måder at fordele forbindelser på for at håndtere sådanne høje belastninger i systemet.
Grundlaget for sådan fordeling ligger i det velkendte (DNS). Dette system tilvejebringer muligheden for at omdanne et domænenavn, såsom en vægtet cirkulær algoritme (weighted round robin) og metoder baseret på forsinkelse, som hjælper med at fordele belastningen.
er helt afgørende, og næsten ethvert stort system på internettet, som vi i dag har med at gøre, ligger bag en eller flere belastningsbalancer. Belastningsbalancer hjælper med at fordele klientanmodninger på tværs af mange tilgængelige instanser. Belastningsbalancere kan være både hardware- og softwarebaserede; dog arbejder man i praksis oftere med softwareløsninger, fx med og . er konceptuelt også meget lig belastningsbalancere, skønt der er en række . Disse forskelle skal der tages højde for, når man designer systemet efter jeres behov.
Det er også vigtigt at vide om (CDN). CDN – et globalt distribueret netværk af proxy-servere, der leverer information fra de noder, der geografisk er placeret tættere på den specifikke bruger. CDN-netværk er at foretrække, hvis du arbejder med statiske filer skrevet i JavaScript, CSS og HTML. Derudover er der i dag mange cloudtjenester, hvor trafikmanagers tilbydes, for eksempel, , som giver dig global distribution og reduceret latenstid ved arbejde med dynamisk indhold. Dog er sådanne tjenester generelt nyttige i situationer, hvor man skal arbejde med tilstandsfrie webtjenester.
Lad os tale om forretningslogik. Strukturering af forretningslogik, opgavernes strømme og komponenter
Så vi har haft mulighed for at diskutere forskellige infrastrukturaspekter af systemet. Sandsynligvis tænker brugeren slet ikke på alle disse elementer i dit system og er helt ærligt ligeglad med dem. Brugeren er interesseret i, hvordan det er at interagere med dit system, hvad man kan opnå ved at gøre det på den måde, samt hvordan systemet udfører brugerens kommandoer, hvad der gøres med brugerens data.
Som det fremgår af titlen på denne artikel, havde jeg til hensigt at tale om softwarearkitektur og systemdesign. Derfor havde jeg ikke planlagt at dække designmønstre, der beskriver, hvordan softwarekomponenter skabes. Dog, jo mere jeg tænker over det, jo mere synes jeg, at grænsen mellem designmønstre og arkitektoniske mønstre er meget uklar, og de to begreber er nært relaterede. Tag for eksempel (event sourcing). Når du tager dette arkitektoniske mønster i brug, vil det påvirke næsten alle aspekter af dit system: langvarig datalagring, det niveau af konsistens, der er accepteret i dit system, konturerne af komponenterne i det, osv. Derfor har jeg besluttet at nævne nogle arkitektoniske mønstre, der direkte relaterer sig til forretningslogikken. Selvom denne artikel måske kun må begrænses til en simpel liste, anbefaler jeg, at du sætter dig ind i den og overvejer de ideer, der er relateret til disse mønstre. Her er de:
- Konceptene , især ,
Kollaborative tilgange
Det er yderst usandsynligt, at du vil være den eneste deltager på et projekt, der har det fulde ansvar for systemdesignprocessen. Tværtimod vil du sandsynligvis skulle samarbejde med kolleger, der arbejder både inden for og uden for din opgave. I dette tilfælde kan det være nødvendigt at evaluere de valgte teknologiske løsninger sammen med kolleger, udskille forretningsbehov og forstå, hvordan opgaver bedst kan paralleliseres.
Billede fra Unsplash
Først og fremmest skal der udvikles en præcis og anerkendt forståelse af, hvad det forretningsmål er, som du forsøger at opnå, og hvilke variable elementer der skal tages højde for. Teknikker til gruppemodellering, især hjælper betydeligt med at fremskynde denne proces og øger dine chancer for succes. Dette arbejde kan udføres før eller efter du har skitseret , for derefter at uddybe det, efterhånden som produktet modnes. Baseret på det niveau af enighed, der opnås her, kan du også formulere for det begrænsede kontekst, du arbejder i. Når du skal kommunikere om din systems arkitektur, kan en , foreslået af , især være nyttig, når det er nødvendigt at forstå, hvor meget du skal dykke ned i detaljerne, visualisere de ting, du ønsker at kommunikere.
Det er sandsynligt, at der er andre modne teknologier inden for dette emne, der er lige så nyttige som emneorienteret design. Men vi vender alligevel tilbage til forståelsen af emneområdet, så viden og erfaring inden for bør komme dig til gode.
Kilde: habr.com
