Klient-server-arkitektur

1.1 Applikationsarkitektur

Den här kursen är designad för nybörjare, eftersom du inte kommer att designa arkitekturen för en seriös applikation på länge. Men oroa dig inte, bra arkitektur är undantaget snarare än regeln. Det är mycket svårt att välja rätt applikationsarkitektur innan man bygger applikationen.

Exempel på populära arkitekturer för stora serverapplikationer:

• Skiktad arkitektur (Layered Architecture).
• Tiered arkitektur.
• Service Oriented Architecture (SOA).
• Mikroservicearkitektur (Microservice Architecture).

Var och en av dem har sina för- och nackdelar. Men att studera dem ger dig ingenting. Arkitektur är svaret på frågan "hur man organiserar interaktionen mellan tusentals objekt i systemet" . Och tills du upplever problemets fulla komplexitet kommer du inte att kunna förstå lösningens fulla mångsidighet.

Alla applikationer använder någon form av arkitektur, eller åtminstone låtsas det. Därför kommer kunskap om populära tillvägagångssätt för applikationsdesign att göra det möjligt för dig att snabbt och bättre förstå hur applikationen fungerar. Och det innebär att göra ändringar precis där du behöver dem.

Vad betyder "gör förändringar där det behövs"? Finns det platser där du inte behöver göra ändringar? Exakt.

För att vara specifik, låt oss säga att du arbetar med ett medelstort backend-projekt . Den har skrivits i 5 år av ett team på 20 personer. Projektet tog 100 manår och innehåller cirka 100 tusen rader kod. Totalt består den av två tusen klasser, som är uppdelade i 10 moduler av olika storlekar.

Och lägg till en hård verklighet. Logiken i vissa uppgifter är spridd över flera moduler. Dessutom kan affärslogik finnas i frontend (skriven i JavaScript) och/eller skriven som en lagrad procedur direkt i databasen. Är du fortfarande säker på att du omedelbart kan bestämma var exakt du ska göra ändringar ?

Det här är inte någon mardröm jag hittade på för att skrämma dig. Detta är ett typiskt projekt. Det händer ännu värre. Varför händer det här? Det kan finnas hur många orsaker som helst, men nästan alltid finns det sådana:

• Många människor arbetar med projektet - var och en av dem ser det lite olika.
• I 5 år har 10 personer förändrats i projektet, nykomlingar förstod det inte mycket.
• Att skapa mjukvara är en ständig förändring som ständigt förändrar allt.
• För fem år sedan, när vi bestämde oss för arkitekturen, var idén med projektet något annorlunda.

Men det viktigaste är att oavsett projektets arkitektur höll alla programmerare som arbetade med det samma förståelse för hur det här projektet fungerar. Låt oss börja med det enklaste konceptet - klient-server-arkitektur.

1.2 Begreppet klient-server-interaktion

Nu kommer vi att förstå konceptet som ligger till grund för klient-server- arkitekturen och kommer att tillåta dig att bättre förstå hur interaktionen mellan miljontals program på Internet är organiserad.

Som namnet antyder involverar detta koncept två parter: klient och server . Allt är som i livet här: klienten är kund till den eller den tjänsten, och servern är tjänsteleverantören. Klienten och servern är fysiskt program , till exempel är en typisk klient en webbläsare .

Följande exempel kan ges som en server:

• Webbservrar som Tomcat.
• Databasservrar som MySQL.
• Betalningsgateways som Stripe.

Klienten och servern kommunicerar vanligtvis via Internet (även om de kan fungera i samma lokala nätverk och i allmänhet i alla andra typer av nätverk). Kommunikation sker över standardprotokoll som HTTP, FTP eller lägre nivåprotokoll som TCP eller UDP.

Protokollet väljs vanligtvis efter vilken typ av tjänst som servrarna tillhandahåller. Om det till exempel är ett videosamtal används vanligtvis UDP.

Kommer du ihåg hur Tomcat och dess servlets fungerar? Servern tar emot ett HTTP-meddelande, packar upp det, extraherar all nödvändig information därifrån och skickar den till servleten för bearbetning. Därefter packas bearbetningsresultatet tillbaka till ett HTTP-svar och skickas till klienten.

Detta är den typiska klient-server-interaktionen. Webbläsaren är webbklienten och Tomcat är webbservern. Tomcat kallas till och med en webbserver.

Men om man tänker efter så är det inte namnet som är det viktiga, utan essensen – rollfördelningen mellan programmen. Ditt JS-skript som körs på en HTML-sida kan mycket väl kallas en klient och din servlet en server . De arbetar trots allt i par inom ramen för klient-server-konceptet .

1.3 En viktig nyans

Det är också värt att notera att klient-server-interaktionen bygger på principen att sådan interaktion initieras av klienten : servern svarar bara klienten och rapporterar om den kan tillhandahålla tjänsten till klienten och i så fall på vilka villkor .

Det spelar ingen roll var klienten är fysiskt placerad och var servern är. Klientmjukvaran och servermjukvaran är vanligtvis installerad på olika maskiner, men de kan också köras på samma dator.

Detta koncept utvecklades som ett första steg mot att förenkla ett komplext system. Hon har dessa styrkor:

• Logisk förenkling : servern vet ingenting om klienten och hur den kommer att använda sina data i framtiden.
• Det kan finnas svaga klienter : alla resurskrävande uppgifter kan överföras till servern.
• Oberoende utveckling av klientkod och serverkod.
• Många olika klienter, till exempel Tomcat och olika webbläsare.

Den mest grundläggande versionen av interaktionen mellan klienten och servern visas på bilden:

Det är viktigt att notera två detaljer här. Först visar bilden att många klienter kan komma åt en server. För det andra kan de komma åt det samtidigt. Detta är också en viktig del av servern.

En klient interagerar vanligtvis med en användare, så ofta behövs inte ens auktorisering där. Servern bearbetar dock förfrågningar från tusentals klienter och när du utvecklar kod för den måste du kunna skilja på auktorisering och autentisering.

Det är också viktigt att servern behandlar tusentals förfrågningar parallellt. Och detta betyder att när du utvecklar backend-koden kommer du ständigt behöva tänka på uppgiften med samtidig tillgång till resurser. Serverkoden har också en mycket hög sannolikhet för rastillstånd (trådlopp), dödläge (ömsesidig blockering av trådar).

Livscykeln för viktiga objekt måste övervakas:

Du kan inte bara starta en ny tråd på servern via new Thread().start(). Istället måste du ha en ThreadPool som delar mellan alla tjänsttrådar.

Dessutom kan du inte bara starta en asynkron uppgift, eftersom de också körs i separata trådar. När du skapar en sådan uppgift bör du alltid veta vilken pool av trådar som kör den och vad som kommer att hända om en sådan pool svämmar över.

Allt arbete med filer och kataloger måste göras genom prova-med-resurser. Om du i en vanlig applikation glömde att stänga en stream eller en fil, är det ett problem? Den stänger sig själv när du avslutar programmet. Men om du glömde att stänga en fil på servern någonstans i koden, och din server har körts i månader ... Snart kommer tusentals sådana ostängda filer att samlas och operativsystemet kommer att sluta öppna nya filer för läsning (arbeta med filer styrs av operativsystemet). Teamlead kommer inte att klappa dig på huvudet...

1.4 Klient-server-arkitektur

en annan viktig punkt. Klient-server-arkitekturen definierar endast de allmänna principerna för interaktion mellan datorer, detaljerna i interaktionen bestäms av olika protokoll.

Detta koncept (klient-server) talar om för oss att vi måste dela upp maskinerna på nätverket i klientmaskiner, som alltid behöver något, och servermaskiner, som ger vad de behöver. I det här fallet startar klienten alltid interaktionen och reglerna för interaktionen beskrivs av protokollet.

Det finns två typer av klient-server-interaktionsarkitektur: den första kallas tvåstegs klient-server- arkitektur , den andra är multi-nivå klient-server-arkitektur (kallas ibland en tre-nivå arkitektur eller en tre-nivå arkitektur, men detta är ett specialfall).

Principen för driften av tvåskiktsarkitekturen för klient-server-interaktion är att behandlingen av en begäran sker på en server utan att hänvisa till andra servrar i processen för denna bearbetning.

Den tvåstegiga klient-serverinteraktionsmodellen kan ritas som ett enkelt diagram.

Här kan du se att den första nivån är allt som rör klienten, och den andra nivån är allt som rör servern.