1.1 Applikationsarkitektur
Dette kursus er designet til begyndere, fordi du ikke vil designe arkitekturen for en seriøs applikation i lang tid. Men bare rolig, god arkitektur er undtagelsen snarere end reglen. Det er meget svært at vælge den rigtige applikationsarkitektur, før applikationen bygges.
Eksempler på populære arkitekturer til store serverapplikationer:
- Lagdelt arkitektur (Layered Architecture).
- Tierdelt arkitektur.
- Serviceorienteret arkitektur (SOA).
- Mikroservicearkitektur (Microservice Architecture).
Hver af dem har sine fordele og ulemper. Men at studere dem vil ikke give dig noget. Arkitektur er svaret på spørgsmålet "hvordan man organiserer interaktionen mellem tusindvis af objekter i systemet" . Og før du oplever problemets fulde kompleksitet, vil du ikke være i stand til at forstå løsningens fulde alsidighed.
Alle applikationer bruger en form for arkitektur, eller i det mindste foregiver det. Derfor vil viden om populære tilgange til applikationsdesign give dig mulighed for hurtigt og bedre at forstå, hvordan applikationen fungerer. Og det betyder, at du skal foretage ændringer, præcis hvor du har brug for dem.
Hvad betyder "foretag ændringer, hvor det er nødvendigt"? Er der steder, hvor du ikke behøver at foretage ændringer? Nemlig.
For at være specifikke, lad os sige, at du arbejder på et medium backend-projekt . Den er skrevet i 5 år af et hold på 20 personer. Projektet tog 100 mandår og indeholder omkring 100 tusind linjer kode. I alt består det af to tusinde klasser, som er opdelt i 10 moduler af forskellig størrelse.
Og tilføje en barsk virkelighed. Logikken i nogle opgaver er spredt over flere moduler. Forretningslogik kan også være i frontend (skrevet i JavaScript) og/eller skrevet som en lagret procedure direkte i databasen. Er du stadig sikker på, at du med det samme kan bestemme det sted, hvor du præcist skal foretage ændringer ?
Det er ikke et mareridt, jeg har fundet på for at skræmme dig. Dette er et typisk projekt. Det sker endnu værre. Hvorfor sker dette? Der kan være en række årsager, men næsten altid er der sådanne:
- Mange mennesker arbejder på projektet – hver af dem ser det lidt forskelligt.
- I 5 år har 10 personer ændret sig i projektet, nytilkomne forstod det ikke meget.
- At skabe software er en konstant fremstilling af ændringer, der konstant ændrer alt.
- For fem år siden, da vi besluttede os for arkitekturen, var idéen med projektet noget anderledes.
Men det vigtigste er, at uanset projektets arkitektur holdt alle de programmører, der arbejdede på det, den samme forståelse af, hvordan dette projekt fungerer. Lad os starte med det enkleste koncept - klient-server-arkitektur.
1.2 Begrebet klient-server-interaktion
Nu vil vi forstå konceptet, der ligger til grund for klient-server- arkitekturen , og vil give dig mulighed for bedre at forstå, hvordan interaktionen mellem millioner af programmer på internettet er organiseret.
Som navnet antyder, involverer dette koncept to parter: klient og server . Alt er som i livet her: klienten er kunde af denne eller hin tjeneste, og serveren er tjenesteudbyderen. Klienten og serveren er fysisk programmer , f.eks. er en typisk klient en browser .
Følgende eksempler kan gives som server:
- Webservere såsom Tomcat.
- Databaseservere såsom MySQL.
- Betalings-gateways som Stripe.
Klienten og serveren kommunikerer normalt via internettet (selvom de kan arbejde i det samme lokale netværk og generelt i alle andre typer netværk). Kommunikation foregår over standardprotokoller såsom HTTP, FTP eller lavere niveauprotokoller såsom TCP eller UDP.
Protokollen vælges normalt i henhold til den type service, som serverne leverer. For eksempel, hvis det er et videoopkald, så bruges UDP normalt.
Kan du huske, hvordan Tomcat og dens servlets fungerer? Serveren modtager en HTTP-meddelelse, pakker den ud, udtrækker al den nødvendige information derfra og sender den til servlet'en til behandling. Derefter pakkes behandlingsresultatet tilbage i et HTTP-svar og sendes til klienten.
Dette er den typiske klient-server-interaktion. Browseren er webklienten og Tomcat er webserveren. Tomcat kaldes endda en webserver.
Men hvis man tænker over det, er det ikke navnet, der er vigtigt, men essensen – rollefordelingen mellem programmerne. Dit JS-script, der kører på en HTML-side, kunne godt kaldes en klient , og din servlet en server . De arbejder jo i par inden for rammerne af klient-server-konceptet .
1.3 En vigtig nuance
Det er også værd at bemærke, at klient-server-interaktionen er baseret på princippet om, at en sådan interaktion initieres af klienten : serveren svarer kun klienten og rapporterer, om den kan levere tjenesten til klienten og i givet fald på hvilke betingelser .
Det er lige meget, hvor klienten fysisk er placeret, og hvor serveren er. Klientsoftwaren og serversoftwaren er normalt installeret på forskellige maskiner, men de kan også køre på den samme computer.
Dette koncept blev udviklet som et første skridt mod at forenkle et komplekst system. Hun har disse styrker:
- Logisk forenkling : serveren ved ikke noget om klienten, og hvordan den vil bruge sine data i fremtiden.
- Der kan være svage klienter : alle ressourcekrævende opgaver kan overføres til serveren.
- Selvstændig udvikling af klientkode og serverkode.
- Masser af forskellige klienter, for eksempel Tomcat og forskellige browsere.
Den mest grundlæggende version af interaktionen mellem klienten og serveren er vist på billedet:
Det er vigtigt at bemærke to detaljer her. For det første viser billedet, at mange klienter kan få adgang til én server. For det andet kan de få adgang til det på samme tid. Dette er også en vigtig del af serveren.
Én klient interagerer normalt med én bruger, så ofte er endog autorisation ikke nødvendig der. Serveren behandler dog anmodninger fra tusindvis af klienter, og når du udvikler kode til den, skal du kunne skelne mellem autorisation og autentificering.
Det er også vigtigt, at serveren behandler tusindvis af anmodninger parallelt. Og det betyder, at når du udvikler backend-koden, skal du konstant tænke på opgaven med samtidig adgang til ressourcer. Serverkoden har også en meget høj sandsynlighed for racetilstand (trådløb), dødvande (gensidig blokering af tråde).
Livscyklussen for vigtige genstande skal overvåges:
Du kan ikke bare starte en ny tråd på serveren via new Thread().start(). I stedet skal du have en ThreadPool, der deler mellem alle servicetråde.
Du kan heller ikke bare starte en asynkron opgave, fordi de også udføres i separate tråde. Når du opretter en sådan opgave, bør du altid vide, hvilken pool af tråde, der udfører den, og hvad der vil ske, hvis en sådan pulje løber over.
Alt arbejde med filer og mapper skal udføres gennem prøve-med-ressourcer. Hvis du i en normal applikation har glemt at lukke en stream eller en fil, er det så et problem? Den lukker sig selv, når du afslutter programmet. Men hvis du har glemt at lukke en fil på serveren et eller andet sted i koden, og din server har kørt i flere måneder ... Snart vil tusindvis af sådanne ulukkede filer akkumulere, og OS vil stoppe med at åbne nye filer til læsning (arbejde med filer styres af OS). Teamleder vil ikke klappe dig på hovedet...
1.4 Klient-server-arkitektur
endnu et vigtigt punkt. Klient-server-arkitekturen definerer kun de generelle principper for interaktion mellem computere , detaljerne i interaktionen bestemmes af forskellige protokoller.
Dette koncept (klient-server) fortæller os, at vi skal opdele maskinerne på netværket i klientmaskiner, som altid har brug for noget, og servermaskiner, som giver det, de har brug for. I dette tilfælde starter klienten altid interaktionen, og reglerne for interaktionen er beskrevet af protokollen.
Der er to typer klient-server-interaktionsarkitektur: den første kaldes den to-lags klient-server- arkitektur , den anden er multi-tier klient-server-arkitekturen (nogle gange kaldet en tre-lags arkitektur eller en tre-lags arkitektur, men dette er et særligt tilfælde).
Princippet for driften af den to-lags arkitektur for klient-server-interaktion er, at behandlingen af en anmodning sker på én server uden at henvise til andre servere i processen med denne behandling.
Den to-lags klient-server interaktionsmodel kan tegnes som et simpelt diagram.
Her kan du se, at det første niveau er alt, hvad der vedrører klienten, og det andet niveau er alt, der vedrører serveren.