Hei kollegaer.
I dag tilbyr vi for din vurdering en oversettelse av en artikkel av Tugberk Ugurlu, som påtok seg å skissere i et relativt lite volum prinsippene for å designe moderne programvaresystemer. Her er hva forfatteren sier om seg selv i oppsummering:
Siden det er absolutt umulig å dekke i en habro-artikkel et så kolossalt emne som arkitektoniske mønstre + designmønstre fra 2019, anbefaler vi ikke bare teksten til Mr. Uruglu selv, men også de mange lenkene han vennligst inkluderte i den. Hvis du liker det, vil vi publisere en mer spesialisert tekst om utformingen av distribuerte systemer.
øyeblikksbilde fra Unsplash
Hvis du aldri har måttet møte slike utfordringer som å designe et programvaresystem fra bunnen av, så når du starter slikt arbeid, er det noen ganger ikke engang klart hvor du skal begynne. Jeg tror at du først må trekke grenser slik at du har en mer eller mindre sikker ide om nøyaktig hva du skal designe, og deretter brette opp ermene og jobbe innenfor disse grensene. Som et utgangspunkt kan du ta et produkt eller en tjeneste (ideelt sett en du virkelig liker) og finne ut hvordan du implementerer den. Du kan bli overrasket over hvor enkelt dette produktet ser ut, og hvor mye kompleksitet det faktisk inneholder. Ikke glem: , og det er greit.
Jeg tror det beste rådet jeg kan gi til alle som begynner å designe et system er dette: ikke gjør noen forutsetninger! Helt fra begynnelsen må du spesifisere fakta kjent om dette systemet og forventningene knyttet til det. Her er noen gode spørsmål å stille for å hjelpe deg i gang med designet:
- Hva er problemet vi prøver å løse?
- Hva er det høyeste antallet brukere som vil samhandle med systemet vårt?
- Hvilke mønstre for å skrive og lese data vil vi bruke?
- Hva er de forventede feilsakene, hvordan skal vi håndtere dem?
- Hva er forventningene til systemkonsistens og tilgjengelighet?
- Må du ta hensyn til eventuelle krav knyttet til ekstern verifisering og regulering når du jobber?
- Hvilke typer sensitive data skal vi lagre?
Dette er bare noen få spørsmål som har vært nyttige for både meg og teamene jeg har deltatt i gjennom årene med faglig aktivitet. Hvis du vet svarene på disse spørsmålene (og andre som er relevante for konteksten du må jobbe i), kan du gradvis fordype deg i de tekniske detaljene i problemet.
Still inn startnivået
Hva mener jeg med "grunnlinje" her? Faktisk, i vår tid, "kan" de fleste problemer i programvareindustrien løses ved hjelp av eksisterende metoder og teknologier. Følgelig, ved å navigere i dette landskapet, får du et visst forsprang når du står overfor problemer som noen andre måtte løse før deg. Ikke glem at programmer er skrevet for å løse forretnings- og brukerproblemer, så vi streber etter å løse problemet på den mest greie og enkle (fra brukerens ståsted) måte. Hvorfor er dette viktig å huske? Kanskje i koordinatsystemet ditt liker du å se etter unike løsninger for alle problemer, fordi du tenker «hva slags programmerer er jeg hvis jeg følger mønstre overalt»? Faktisk, kunsten her er å ta avgjørelser om hvor og hva de skal gjøre. Selvfølgelig må hver enkelt av oss håndtere unike problemer fra tid til annen, som hver er en reell utfordring. Men hvis startnivået vårt er klart definert, så vet vi hva vi skal bruke energien vår på: å søke etter ferdige alternativer for å løse problemet satt foran oss, eller studere det videre og få en dypere forståelse.
Jeg tror jeg var i stand til å overbevise deg om at hvis en spesialist selvsikkert forstår hva den arkitektoniske komponenten i noen fantastiske programvaresystemer er, så vil denne kunnskapen være uunnværlig for å mestre en arkitekts kunst og utvikle et solid grunnlag på dette feltet.
Ok, så hvor skal du begynne? U Det er et depot på GitHub som heter , hvorfra du kan lære å designe store systemer, samt forberede deg til intervjuer om dette emnet. Depotet har en seksjon med eksempler , hvor det spesielt vurderes hvordan de nærmer seg utformingen av systemene sine for eksempel Twitter, Uber, etc.
Men før vi går videre til dette materialet, la oss se nærmere på de viktigste arkitektoniske utfordringene vi står overfor i praksis. Dette er viktig fordi man må spesifisere MANGE sider ved et hardnakket og mangefasettert problem, for så å løse det innenfor rammen av gjeldende regelverk i et gitt system. , skrev en tidligere Facebook-ansatt , hvor han delte sin egen erfaring med screening av hundrevis av søkere. Mens videoen fokuserer sterkt på design av store systemer og suksesskriteriene som er viktige når man leter etter en kandidat til en slik stilling, vil den fortsatt tjene som en omfattende ressurs for hva som er viktigst når man designer systemer. Jeg foreslår også denne videoen.
Bygg kunnskap om lagring og gjenfinning av data
Vanligvis har din beslutning om hvordan du lagrer og henter dataene dine på lang sikt en kritisk innvirkning på systemytelsen. Derfor må du først forstå de forventede skrive- og leseegenskapene til systemet ditt. Da må du kunne vurdere disse indikatorene og ta valg basert på de vurderingene som er gjort. Du kan imidlertid effektivt takle dette arbeidet bare hvis du forstår eksisterende datalagringsmønstre. I prinsippet innebærer dette solid kunnskap knyttet til .
Databaser kan betraktes som datastrukturer som er ekstremt skalerbare og holdbare. Derfor bør kunnskap om datastrukturer være svært nyttig for deg når du skal velge en bestemt database. For eksempel, er en datastrukturserver som støtter ulike typer verdier. Den lar deg jobbe med datastrukturer som lister og sett, og lese data ved hjelp av velkjente algoritmer, for eksempel, , organisere slikt arbeid i en holdbar og svært tilgjengelig stil.
øyeblikksbilde fra Unsplash
Når du har en tilstrekkelig forståelse av de ulike datalagringsmønstrene, gå videre til å studere datakonsistens og tilgjengelighet. Først av alt må du forstå i det minste i generelle termer, og deretter polere denne kunnskapen ved å se nærmere på etablerte mønstre и . På denne måten vil du utvikle en forståelse av feltet og forstå at lesing og skriving av data faktisk er to svært forskjellige problemer, hver med sine egne unike utfordringer. Bevæpnet med noen få konsistens- og tilgjengelighetsmønstre kan du øke systemytelsen betydelig samtidig som du sikrer jevn dataflyt til applikasjonene dine.
Til slutt, for å avslutte samtalen om datalagringsproblemer, bør vi også nevne caching. Skal det kjøres samtidig på klienten og serveren? Hvilke data vil være i hurtigbufferen din? Og hvorfor? Hvordan organiserer du cache-ugyldiggjøring? Vil det bli gjort regelmessig, med visse intervaller? Hvis ja, hvor ofte? Jeg anbefaler å begynne å studere disse emnene med den nevnte systemdesignprimeren.
Kommunikasjonsmønstre
Systemer består av ulike komponenter; disse kan være forskjellige prosesser som kjører innenfor samme fysiske node, eller forskjellige maskiner som kjører på forskjellige deler av nettverket ditt. Noen av disse ressursene i nettverket ditt kan være private, men andre bør være offentlige og åpne for forbrukere som får tilgang til dem utenfra.
Det er nødvendig å sikre kommunikasjon av disse ressursene med hverandre, samt utveksling av informasjon mellom hele systemet og omverdenen. I sammenheng med systemdesign står vi her igjen overfor et sett med nye og unike utfordringer. La oss se hvordan de kan være nyttige , og hva s.
øyeblikksbilde fra Unsplash
Når du organiserer kommunikasjon med omverdenen, er det alltid veldig viktig , som også må tas på alvor og aktivt forfølges.
Tilkoblingsdistribusjon
Jeg er ikke sikker på at det vil virke berettiget for alle å sette dette emnet inn i en egen del. Jeg vil likevel presentere dette konseptet i detalj her, og jeg mener at materialet i denne delen er mest nøyaktig beskrevet med begrepet «forbindelsesdistribusjon».
Systemer dannes ved å koble mange komponenter riktig, og deres kommunikasjon med hverandre er ofte organisert på grunnlag av etablerte protokoller, for eksempel TCP og UDP. Imidlertid er disse protokollene som sådan ofte utilstrekkelige for å møte alle behovene til moderne systemer, som ofte drives under høy belastning og også er svært avhengige av brukerbehov. Det er ofte nødvendig å finne måter å distribuere forbindelser for å takle så høye belastninger på systemet.
Denne fordelingen er basert på det velkjente (DNS). Et slikt system tillater domenenavntransformasjoner som vektet round robin og latensbaserte metoder for å hjelpe til med å fordele belastningen.
er grunnleggende viktig, og nesten alle store internettsystemer vi har å gjøre med i dag er plassert bak en eller flere lastbalansere. Lastbalansere hjelper til med å distribuere klientforespørsler på tvers av flere tilgjengelige forekomster. Lastbalansere kommer i både maskinvare og programvare, men i praksis må du oftere forholde deg til programvare, for eksempel и . konseptuelt også veldig lik lastbalansere, selv om det er en rekkevidde mellom første og andre . Disse forskjellene må tas i betraktning når du designer et system basert på dine behov.
Du bør også vite om (CDN). Et CDN er et globalt distribuert nettverk av proxy-servere som leverer informasjon fra noder som er geografisk plassert nærmere en bestemt bruker. CDN-er er å foretrekke å bruke hvis du jobber med statiske filer skrevet i JavaScript, CSS og HTML. I tillegg er skytjenester som gir trafikkledere vanlige i dag, f.eks. , noe som gir deg global distribusjon og redusert ventetid når du arbeider med dynamisk innhold. Slike tjenester er imidlertid vanligvis nyttige i tilfeller der du må jobbe med statsløse nettjenester.
La oss snakke om forretningslogikk. Strukturere forretningslogikk, oppgaveflyt og komponenter
Så vi klarte å diskutere ulike infrastrukturelle aspekter ved systemet. Mest sannsynlig tenker brukeren ikke engang på alle disse elementene i systemet ditt, og ærlig talt bryr han seg ikke om dem i det hele tatt. Brukeren er interessert i hvordan det er å samhandle med systemet ditt, hva som kan oppnås ved å gjøre dette, og også hvordan systemet utfører brukerkommandoer, hva og hvordan det gjør med brukerdata.
Som tittelen på denne artikkelen antyder, skulle jeg snakke om programvarearkitektur og systemdesign. Følgelig planla jeg ikke å dekke programvaredesignmønstre som beskriver hvordan programvarekomponenter lages. Men jo mer jeg tenker på det, jo mer virker det for meg at grensen mellom programvaredesignmønstre og arkitektoniske mønstre er veldig uklare, og de to konseptene er nært beslektet. La oss ta for eksempel (innhenting av hendelser). Når du først tar i bruk dette arkitektoniske mønsteret, vil det påvirke nesten alle aspekter av systemet ditt: langsiktig lagring av data, nivået av konsistens som er tatt i bruk i systemet ditt, formen på komponentene i det, etc., etc., etc. Derfor bestemte jeg meg for å nevne noen arkitektoniske mønstre som direkte relaterer til forretningslogikk. Selv om denne artikkelen må begrense seg til en enkel liste, oppfordrer jeg deg til å gjøre deg kjent med den og tenke på ideene knyttet til disse mønstrene. Vær så god:
- Av konseptet , spesielt, ,
Samarbeidende tilnærminger
Det er ekstremt lite sannsynlig at du vil finne deg selv på et prosjekt som deltakeren som er eneansvarlig for systemdesignprosessen. Tvert imot vil du mest sannsynlig måtte samhandle med kolleger som jobber både innenfor og utenfor oppgaven din. I dette tilfellet må du kanskje evaluere de valgte teknologiløsningene med kolleger, identifisere forretningsbehov og forstå hvordan du best kan parallellisere oppgaver.
øyeblikksbilde fra Unsplash
Det første trinnet er å utvikle en nøyaktig og delt forståelse av hva forretningsmålet du prøver å oppnå er og hvilke bevegelige deler du må forholde deg til. Gruppemodelleringsteknikker, spesielt (hendelsesstorming) bidrar til å fremskynde denne prosessen betydelig og øke sjansene for suksess. Dette arbeidet kan gjøres før eller etter du skisserer , og deretter utdype den etter hvert som produktet modnes. Basert på nivået av konsistens som vil bli oppnådd her, kan du også formulere for den begrensede konteksten du jobber i. Når du trenger å snakke om arkitekturen til systemet ditt, kan du finne det nyttig , foreslått , spesielt når du trenger å forstå hvor mye du må gå inn i detaljene i problemet, visualisere tingene du ønsker å kommunisere.
Det er sannsynligvis en annen moden teknologi om dette emnet som ikke er mindre nyttig enn Domain Driven Design. Vi går imidlertid tilbake til å forstå fagområdet, så kunnskap og erfaring på feltet bør være nyttig for deg.
Kilde: www.habr.com