1.1 Applicatie-architectuur
Deze cursus is bedoeld voor beginners, omdat je lange tijd niet bezig bent met het ontwerpen van de architectuur van een serieuze applicatie. Maar maak je geen zorgen, goede architectuur is eerder uitzondering dan regel. Het is erg moeilijk om de juiste applicatie-architectuur te kiezen voordat de applicatie wordt gebouwd.
Voorbeelden van populaire architecturen voor grote servertoepassingen:
- Gelaagde architectuur (Layered Architecture).
- Gelaagde architectuur.
- Servicegeoriënteerde architectuur (SOA).
- Microservice-architectuur (Microservice-architectuur).
Elk van hen heeft zijn voor- en nadelen. Maar als je ze bestudeert, krijg je niets. Architectuur is het antwoord op de vraag "hoe de interactie van duizenden objecten binnen het systeem te organiseren" . En totdat u de volledige complexiteit van het probleem ervaart, zult u de volledige veelzijdigheid van de oplossing niet kunnen begrijpen.
Alle applicaties gebruiken een soort architectuur, of doen in ieder geval alsof. Kennis van populaire benaderingen van applicatieontwerp stelt u daarom in staat om snel en beter te begrijpen hoe de applicatie werkt. En dat betekent wijzigingen aanbrengen precies daar waar u ze nodig hebt.
Wat betekent "wijzigen waar nodig"? Zijn er plaatsen waar u geen wijzigingen hoeft aan te brengen? Precies.
Om specifiek te zijn, laten we zeggen dat u aan een medium backend-project werkt . Het is gedurende 5 jaar geschreven door een team van 20 mensen. Het project nam 100 manjaren in beslag en bevat ongeveer 100.000 regels code. In totaal bestaat het uit tweeduizend lessen, die zijn onderverdeeld in 10 modules van verschillende groottes.
En voeg een harde realiteit toe. De logica van sommige taken is verdeeld over meerdere modules. Ook kan bedrijfslogica in de frontend staan (geschreven in JavaScript) en/of als een opgeslagen procedure rechtstreeks in de database worden geschreven. Weet u nog zeker dat u direct kunt bepalen waar u precies wijzigingen wilt aanbrengen ?
Dit is niet een nachtmerrie die ik heb verzonnen om je bang te maken. Dit is een typisch project. Het gebeurt nog erger. Waarom gebeurt dit? Er kunnen een aantal redenen zijn, maar bijna altijd zijn er dergelijke:
- Veel mensen werken aan het project - ze zien het allemaal een beetje anders.
- Gedurende 5 jaar zijn 10 mensen veranderd in het project, nieuwkomers begrepen er niet veel van.
- Het maken van software is een constant aanbrengen van veranderingen die constant alles veranderen.
- Vijf jaar geleden, toen we de architectuur bepaalden, was het idee van het project enigszins anders.
Maar het belangrijkste is dat, ongeacht de architectuur van het project, alle programmeurs die eraan werkten hetzelfde begrip hadden van hoe dit project werkt. Laten we beginnen met het eenvoudigste concept: client-serverarchitectuur.
1.2 Het concept van client-server-interactie
Nu zullen we het concept begrijpen dat ten grondslag ligt aan de client-serverarchitectuur en kunt u beter begrijpen hoe de interactie van miljoenen programma's op internet is georganiseerd.
Zoals de naam al aangeeft, zijn er bij dit concept twee partijen betrokken: client en server . Alles is hier zoals in het leven: de klant is de klant van deze of gene dienst en de server is de dienstverlener. De client en server zijn fysieke programma's , een typische client is bijvoorbeeld een browser .
De volgende voorbeelden kunnen als server worden gegeven:
- Webservers zoals Tomcat.
- Databaseservers zoals MySQL.
- Betalingsgateways zoals Stripe.
De client en de server communiceren gewoonlijk via internet (hoewel ze in hetzelfde lokale netwerk kunnen werken en in het algemeen in elk ander type netwerk). Communicatie vindt plaats via standaardprotocollen zoals HTTP, FTP of protocollen op een lager niveau zoals TCP of UDP.
Het protocol wordt meestal gekozen op basis van het type service dat de servers bieden. Gaat het bijvoorbeeld om een videogesprek, dan wordt meestal UDP gebruikt.
Weet je nog hoe Tomcat en zijn servlets werken? De server ontvangt een HTTP-bericht, pakt het uit, haalt alle benodigde informatie eruit en geeft het door aan de servlet voor verwerking. Vervolgens wordt het verwerkingsresultaat verpakt in een HTTP-antwoord en verzonden naar de client.
Dit is de typische client-server-interactie. De browser is de webclient en Tomcat is de webserver. Tomcat wordt zelfs een webserver genoemd.
Maar als je erover nadenkt, is het niet de naam die belangrijk is, maar de essentie - de rolverdeling tussen programma's. Uw JS-script dat in een HTML-pagina draait, zou heel goed een client kunnen worden genoemd , en uw servlet een server . Ze werken immers in paren in het kader van het client-serverconcept .
1.3 Een belangrijke nuance
Het is ook vermeldenswaard dat de client-server-interactie is gebaseerd op het principe dat een dergelijke interactie wordt geïnitieerd door de client : de server antwoordt alleen de client en meldt of hij de service aan de client kan leveren en, zo ja, onder welke voorwaarden .
Het maakt niet uit waar de client zich fysiek bevindt en waar de server zich bevindt. De clientsoftware en serversoftware worden meestal op verschillende machines geïnstalleerd, maar ze kunnen ook op dezelfde computer draaien.
Dit concept is ontwikkeld als een eerste stap op weg naar vereenvoudiging van een complex systeem. Ze heeft deze sterke punten:
- Logische vereenvoudiging : de server weet niets over de klant en hoe hij zijn gegevens in de toekomst zal gebruiken.
- Er kunnen zwakke clients zijn : alle resource-intensieve taken kunnen naar de server worden overgebracht.
- Zelfstandig ontwikkelen van clientcode en servercode.
- Veel verschillende clients, bijvoorbeeld Tomcat en verschillende browsers.
De meest basale versie van de interactie tussen de client en de server wordt weergegeven in de afbeelding:
Het is belangrijk om hier twee details op te merken. Ten eerste laat de afbeelding zien dat veel clients toegang hebben tot één server. Ten tweede hebben ze er tegelijkertijd toegang toe. Dit is ook een belangrijk onderdeel van de server.
Eén client communiceert meestal met één gebruiker, dus vaak is daar zelfs geen autorisatie nodig. De server verwerkt echter verzoeken van duizenden clients en bij het ontwikkelen van code daarvoor moet u onderscheid kunnen maken tussen autorisatie en authenticatie.
Het is ook belangrijk dat de server duizenden verzoeken parallel verwerkt. En dit betekent dat u bij het ontwikkelen van de backend-code voortdurend moet nadenken over de taak van gelijktijdige toegang tot bronnen. Ook heeft de servercode een zeer grote kans op raceconditie (thread race), impasse (wederzijds blokkeren van threads).
De levenscyclus van belangrijke objecten moet worden bewaakt:
Je kunt niet zomaar een nieuwe thread starten op de server via new Thread().start(). In plaats daarvan moet u een ThreadPool hebben die wordt gedeeld tussen alle servicethreads.
Ook kun je niet zomaar een asynchrone taak starten, want die worden ook in aparte threads uitgevoerd. Wanneer u een dergelijke taak maakt, moet u altijd weten welke pool van threads deze uitvoert en wat er zal gebeuren als een dergelijke pool overstroomt.
Al het werk met bestanden en mappen moet worden gedaan via try-with-resources. Als u in een normale toepassing bent vergeten een stream of bestand te sluiten, is dat dan een probleem? Het sluit zichzelf wanneer u het programma verlaat. Maar als u ergens in de code bent vergeten een bestand op de server te sluiten en uw server al maanden draait ... Binnenkort zullen duizenden van dergelijke niet-gesloten bestanden zich ophopen en zal het besturingssysteem stoppen met het openen van nieuwe bestanden om te lezen (werken met bestanden wordt bestuurd door het besturingssysteem). Teamlead geeft je geen schouderklopje...
1.4 Client-server-architectuur
nog een belangrijk punt. De client-serverarchitectuur definieert alleen de algemene principes van interactie tussen computers , de details van de interactie worden bepaald door verschillende protocollen.
Dit concept (client-server) vertelt ons dat we de machines op het netwerk moeten verdelen in clientmachines, die altijd iets nodig hebben, en servermachines, die geven wat ze nodig hebben. In dit geval start de cliënt altijd de interactie, en de regels volgens welke de interactie plaatsvindt, worden beschreven door het protocol.
Er zijn twee typen client-server-interactiearchitectuur: de eerste wordt de two-tier client-server- architectuur genoemd, de tweede is de multi-tier client-server-architectuur (ook wel een three-tier-architectuur of een three-tier-architectuur genoemd, maar dit is een speciaal geval).
Het werkingsprincipe van de tweelaagse architectuur van client-server-interactie is dat de verwerking van een verzoek op één server plaatsvindt zonder naar andere servers te verwijzen tijdens het proces van deze verwerking.
Het two-tier client-server interactiemodel kan worden getekend als een eenvoudig diagram.
Hier zie je dat het eerste niveau alles is wat de client aangaat, en het tweede niveau alles wat de server betreft.