Klient-server-arkitektur

1.1 Applikasjonsarkitektur

Dette kurset er designet for nybegynnere, fordi du ikke vil designe arkitekturen til en seriøs applikasjon på lenge. Men ikke bekymre deg, god arkitektur er unntaket snarere enn regelen. Det er veldig vanskelig å velge riktig applikasjonsarkitektur før applikasjonen bygges.

Eksempler på populære arkitekturer for store serverapplikasjoner:

• Lagdelt arkitektur (Layered Architecture).
• Lagdelt arkitektur.
• Service Oriented Architecture (SOA).
• Mikrotjenestearkitektur (Mikrotjenestearkitektur).

Hver av dem har sine fordeler og ulemper. Men å studere dem vil ikke gi deg noe. Arkitektur er svaret på spørsmålet "hvordan organisere interaksjonen mellom tusenvis av objekter i systemet" . Og før du opplever problemets fulle kompleksitet, vil du ikke kunne forstå den fulle allsidigheten til løsningen.

Alle applikasjoner bruker en slags arkitektur, eller i det minste later som det. Derfor vil kunnskap om populære tilnærminger til applikasjonsdesign tillate deg å raskt og bedre forstå hvordan applikasjonen fungerer. Og det betyr å gjøre endringer akkurat der du trenger dem.

Hva betyr «gjør endringer der det er nødvendig»? Er det steder du ikke trenger å gjøre endringer? Nøyaktig.

For å være spesifikk, la oss si at du jobber med et middels backend-prosjekt . Den har blitt skrevet i 5 år av et team på 20 personer. Prosjektet tok 100 årsverk og inneholder rundt 100 tusen linjer med kode. Totalt består den av to tusen klasser, som er delt inn i 10 moduler i forskjellige størrelser.

Og legg til en tøff virkelighet. Logikken til noen oppgaver er spredt over flere moduler. Dessuten kan forretningslogikk være i frontend (skrevet i JavaScript) og/eller skrevet som en lagret prosedyre direkte i databasen. Er du fortsatt sikker på at du umiddelbart kan finne ut hvor du skal gjøre endringer ?

Dette er ikke et mareritt jeg har funnet på for å skremme deg. Dette er et typisk prosjekt. Det skjer enda verre. Hvorfor skjer dette? Det kan være en rekke årsaker, men nesten alltid er det slike:

• Mange mennesker jobber med prosjektet – hver av dem ser det litt forskjellig.
• I 5 år har 10 personer endret seg i prosjektet, nykommere forsto det ikke mye.
• Å lage programvare er en konstant endring av endringer som hele tiden endrer alt.
• For fem år siden, da vi bestemte oss for arkitekturen, var ideen om prosjektet noe annerledes.

Men det viktigste er at uavhengig av arkitekturen til prosjektet, fulgte alle programmererne som jobbet med det den samme forståelsen av hvordan dette prosjektet fungerer. La oss starte med det enkleste konseptet - klient-server-arkitektur.

1.2 Konseptet klient-server-interaksjon

Nå vil vi forstå konseptet som ligger til grunn for klient-server- arkitekturen og vil tillate deg å bedre forstå hvordan interaksjonen mellom millioner av programmer på Internett er organisert.

Som navnet tilsier, involverer dette konseptet to parter: klient og server . Alt er som i livet her: klienten er kunden til denne eller den tjenesten, og serveren er tjenesteleverandøren. Klienten og serveren er fysisk programmer , for eksempel er en typisk klient en nettleser .

Følgende eksempler kan gis som en server:

• Webservere som Tomcat.
• Databaseservere som MySQL.
• Betalingsporter som Stripe.

Klienten og serveren kommuniserer vanligvis via Internett (selv om de kan fungere i det samme lokale nettverket og generelt i alle andre typer nettverk). Kommunikasjon foregår over standardprotokoller som HTTP, FTP eller lavere nivåprotokoller som TCP eller UDP.

Protokollen velges vanligvis i henhold til typen tjeneste serverne tilbyr. For eksempel, hvis det er en videosamtale, brukes vanligvis UDP.

Husker du hvordan Tomcat og dens servlets fungerer? Serveren mottar en HTTP-melding, pakker den ut, trekker ut all nødvendig informasjon derfra og sender den til servleten for behandling. Deretter pakkes behandlingsresultatet tilbake til et HTTP-svar og sendes til klienten.

Dette er den typiske klient-server-interaksjonen. Nettleseren er webklienten og Tomcat er webserveren. Tomcat kalles til og med en webserver.

Men hvis du tenker deg om, er det ikke navnet som er viktig, men essensen – rollefordelingen mellom programmene. JS-skriptet ditt som kjører på en HTML-side kan godt kalles en klient , og servleten din en server . Tross alt jobber de i par innenfor rammen av klient-server-konseptet .

1.3 En viktig nyanse

Det er også verdt å merke seg at klient-server-interaksjonen er basert på prinsippet om at slik interaksjon initieres av klienten : serveren svarer kun klienten og rapporterer om den kan levere tjenesten til klienten og i så fall på hvilke betingelser .

Det spiller ingen rolle hvor klienten fysisk befinner seg og hvor serveren er. Klientprogramvaren og serverprogramvaren er vanligvis installert på forskjellige maskiner, men de kan også kjøres på samme datamaskin.

Dette konseptet ble utviklet som et første skritt mot å forenkle et komplekst system. Hun har disse styrkene:

• Logisk forenkling : serveren vet ikke noe om klienten og hvordan den vil bruke dataene sine i fremtiden.
• Det kan være svake klienter : alle ressurskrevende oppgaver kan overføres til serveren.
• Selvstendig utvikling av klientkode og serverkode.
• Mange forskjellige klienter, for eksempel Tomcat og forskjellige nettlesere.

Den mest grunnleggende versjonen av interaksjonen mellom klienten og serveren er vist på bildet:

Det er viktig å merke seg to detaljer her. Først viser bildet at mange klienter kan få tilgang til én server. For det andre kan de få tilgang til den samtidig. Dette er også en viktig del av serveren.

Én klient samhandler vanligvis med én bruker, så ofte er til og med autorisasjon ikke nødvendig der. Serveren behandler imidlertid forespørsler fra tusenvis av klienter, og når du utvikler kode for den, må du kunne skille mellom autorisasjon og autentisering.

Det er også viktig at serveren behandler tusenvis av forespørsler parallelt. Og dette betyr at når du utvikler backend-koden, må du hele tiden tenke på oppgaven med samtidig tilgang til ressurser. Serverkoden har også en svært høy sannsynlighet for rasetilstand (trådløp), dødlås (gjensidig blokkering av tråder).

Livssyklusen til viktige objekter må overvåkes:

Du kan ikke bare starte en ny tråd på serveren via new Thread().start(). I stedet må du ha en ThreadPool som vil dele mellom alle tjenestetråder.

Du kan heller ikke bare starte en asynkron oppgave, fordi de også utføres i separate tråder. Når du oppretter en slik oppgave, bør du alltid vite hvilken pool av tråder som utfører den og hva som vil skje hvis en slik pool renner over.

Alt arbeid med filer og kataloger må gjøres gjennom prøv-med-ressurser. Hvis du glemte å lukke en strøm eller en fil i en vanlig applikasjon, er det et problem? Den lukker seg selv når du avslutter programmet. Men hvis du glemte å lukke en fil på serveren et sted i koden, og serveren din har kjørt i flere måneder ... Snart vil tusenvis av slike ulukkede filer samle seg og OS vil slutte å åpne nye filer for lesing (arbeid med filer) styres av operativsystemet). Teamleder vil ikke klappe deg på hodet...

1.4 Klient-server-arkitektur

et annet viktig poeng. Klient-server-arkitekturen definerer bare de generelle prinsippene for interaksjon mellom datamaskiner , detaljene i interaksjonen bestemmes av forskjellige protokoller.

Dette konseptet (klient-server) forteller oss at vi må dele opp maskinene på nettverket i klientmaskiner, som alltid trenger noe, og servermaskiner som gir det de trenger. I dette tilfellet starter klienten alltid interaksjonen, og reglene som interaksjonen skjer etter er beskrevet av protokollen.

Det er to typer klient-tjener-interaksjonsarkitektur: den første kalles to -lags klient-server- arkitektur , den andre er flerlags klient-server-arkitektur (noen ganger kalt en tre-lags arkitektur eller en tre-lags arkitektur, men dette er et spesielt tilfelle).

Prinsippet for driften av tolagsarkitekturen for klient-server-interaksjon er at behandlingen av en forespørsel skjer på en server uten å referere til andre servere i prosessen med denne behandlingen.

Den to-lags klient-server interaksjonsmodellen kan tegnes som et enkelt diagram.

Her kan du se at det første nivået er alt som angår klienten, og det andre nivået er alt som angår serveren.