Client-Server-Architektur

1.1 Anwendungsarchitektur

Dieser Kurs richtet sich an Anfänger, da Sie die Architektur einer ernsthaften Anwendung nicht über einen längeren Zeitraum entwerfen werden. Aber keine Sorge, gute Architektur ist eher die Ausnahme als die Regel. Es ist sehr schwierig, vor dem Erstellen der Anwendung die richtige Anwendungsarchitektur auszuwählen .

Beispiele beliebter Architekturen für große Serveranwendungen:

• Schichtarchitektur (Schichtarchitektur).
• Abgestufte Architektur.
• Serviceorientierte Architektur (SOA).
• Microservice-Architektur (Microservice-Architektur).

Jeder von ihnen hat seine Vor- und Nachteile. Aber sie zu studieren wird Ihnen nichts bringen. Architektur ist die Antwort auf die Frage „Wie organisiert man das Zusammenspiel von Tausenden von Objekten innerhalb des Systems? “ Und solange Sie nicht die volle Komplexität des Problems kennen, werden Sie die volle Vielseitigkeit der Lösung nicht verstehen können.

Alle Anwendungen verwenden irgendeine Art von Architektur oder tun zumindest so. Daher können Sie durch Kenntnisse gängiger Ansätze zum Anwendungsdesign schnell und besser verstehen, wie die Anwendung funktioniert. Und das bedeutet, Änderungen genau dort vorzunehmen, wo Sie sie brauchen.

Was bedeutet „Änderungen vornehmen, wo nötig“? Gibt es Stellen, an denen Sie keine Änderungen vornehmen müssen? Exakt.

Um genau zu sein, nehmen wir an, Sie arbeiten an einem mittelgroßen Backend-Projekt . Es wurde fünf Jahre lang von einem Team aus 20 Personen geschrieben. Das Projekt dauerte 100 Mannjahre und umfasste etwa 100.000 Codezeilen. Insgesamt besteht es aus zweitausend Klassen, die in 10 Module unterschiedlicher Größe unterteilt sind.

Und fügen Sie eine harte Realität hinzu. Die Logik einiger Aufgaben ist auf mehrere Module verteilt. Außerdem kann die Geschäftslogik im Frontend (in JavaScript geschrieben) und/oder als gespeicherte Prozedur direkt in der Datenbank geschrieben sein. Sind Sie immer noch sicher, dass Sie sofort erkennen können, wo genau Sie Änderungen vornehmen müssen ?

Das ist kein Albtraum, den ich mir ausgedacht habe, um dir Angst zu machen. Dies ist ein typisches Projekt. Es passiert noch schlimmer. Warum passiert das? Es kann viele Gründe geben, aber fast immer sind es solche:

• An dem Projekt arbeiten viele Leute – jeder von ihnen sieht es etwas anders.
• 5 Jahre lang haben sich 10 Leute im Projekt verändert, Neulinge haben es nicht viel verstanden.
• Beim Erstellen von Software werden ständig Änderungen vorgenommen, die ständig alles verändern.
• Als wir uns vor fünf Jahren für die Architektur entschieden haben, war die Idee des Projekts etwas anders.

Aber die Hauptsache ist, dass alle daran arbeitenden Programmierer unabhängig von der Architektur des Projekts das gleiche Verständnis davon hatten, wie dieses Projekt funktioniert. Beginnen wir mit dem einfachsten Konzept – der Client-Server-Architektur.

1.2 Das Konzept der Client-Server-Interaktion

Jetzt werden wir das Konzept verstehen, das der Client-Server- Architektur zugrunde liegt , und es Ihnen ermöglichen, besser zu verstehen, wie die Interaktion von Millionen von Programmen im Internet organisiert ist.

Wie der Name schon sagt, umfasst dieses Konzept zwei Parteien: Client und Server . Hier ist alles wie im Leben: Der Kunde ist der Kunde dieses oder jenes Dienstes und der Server ist der Dienstanbieter. Der Client und der Server sind physikalische Programme , ein typischer Client ist beispielsweise ein Browser .

Als Server können folgende Beispiele genannt werden:

• Webserver wie Tomcat.
• Datenbankserver wie MySQL.
• Zahlungsgateways wie Stripe.

Der Client und der Server kommunizieren normalerweise über das Internet (obwohl sie im selben lokalen Netzwerk und im Allgemeinen in allen anderen Netzwerktypen arbeiten können). Die Kommunikation erfolgt über Standardprotokolle wie HTTP, FTP oder untergeordnete Protokolle wie TCP oder UDP.

Das Protokoll wird normalerweise entsprechend der Art des von den Servern bereitgestellten Dienstes ausgewählt. Wenn es sich beispielsweise um einen Videoanruf handelt, wird normalerweise UDP verwendet.

Erinnern Sie sich, wie Tomcat und seine Servlets funktionieren? Der Server empfängt eine HTTP-Nachricht, entpackt sie, extrahiert daraus alle notwendigen Informationen und übergibt sie zur Verarbeitung an das Servlet. Anschließend wird das Verarbeitungsergebnis wieder in eine HTTP-Antwort verpackt und an den Client gesendet.

Dies ist die typische Client-Server-Interaktion. Der Browser ist der Webclient und Tomcat ist der Webserver. Tomcat wird sogar als Webserver bezeichnet.

Aber wenn man darüber nachdenkt, ist nicht der Name wichtig, sondern das Wesentliche – die Rollenverteilung zwischen den Programmen. Ihr JS-Skript, das in einer HTML-Seite ausgeführt wird, könnte durchaus als Client und Ihr Servlet als Server bezeichnet werden . Schließlich arbeiten sie im Rahmen des Client-Server-Konzepts paarweise .

1.3 Eine wichtige Nuance

Es ist auch erwähnenswert, dass die Client-Server-Interaktion auf dem Prinzip basiert, dass eine solche Interaktion vom Client initiiert wird : Der Server antwortet dem Client nur und meldet, ob er den Dienst für den Client bereitstellen kann und wenn ja, zu welchen Bedingungen .

Es spielt keine Rolle, wo sich der Client physisch befindet und wo sich der Server befindet. Die Client-Software und die Server-Software werden in der Regel auf unterschiedlichen Rechnern installiert, können aber auch auf demselben Rechner laufen.

Dieses Konzept wurde als erster Schritt zur Vereinfachung eines komplexen Systems entwickelt. Sie hat diese Stärken:

• Vereinfachung der Logik : Der Server weiß nichts über den Client und wie er seine Daten in Zukunft verwenden wird.
• Möglicherweise gibt es schwache Clients : Alle ressourcenintensiven Aufgaben können auf den Server übertragen werden.
• Unabhängige Entwicklung von Client-Code und Server-Code.
• Viele verschiedene Clients, zum Beispiel Tomcat und verschiedene Browser.

Die einfachste Version der Interaktion zwischen Client und Server ist im Bild dargestellt:

Hier ist es wichtig, zwei Details zu beachten. Das Bild zeigt zunächst, dass viele Clients auf einen Server zugreifen können. Zweitens können sie gleichzeitig darauf zugreifen. Dies ist auch ein wichtiger Teil des Servers.

Normalerweise interagiert ein Client mit einem Benutzer, sodass dort oft nicht einmal eine Autorisierung erforderlich ist. Allerdings verarbeitet der Server Anfragen von Tausenden von Clients, und wenn Sie Code dafür entwickeln, müssen Sie in der Lage sein, zwischen Autorisierung und Authentifizierung zu unterscheiden.

Wichtig ist auch, dass der Server Tausende von Anfragen parallel verarbeitet. Und das bedeutet, dass Sie bei der Entwicklung des Backend-Codes ständig über die Aufgabe des gleichzeitigen Zugriffs auf Ressourcen nachdenken müssen. Außerdem weist der Servercode eine sehr hohe Wahrscheinlichkeit einer Race-Bedingung (Thread-Race) und eines Deadlocks (gegenseitiges Blockieren von Threads) auf.

Der Lebenszyklus wichtiger Objekte muss überwacht werden:

Sie können nicht einfach über einen neuen Thread auf dem Server starten new Thread().start(). Stattdessen benötigen Sie einen ThreadPool, der von allen Service-Threads gemeinsam genutzt wird.

Außerdem können Sie nicht einfach eine asynchrone Aufgabe starten, da diese auch in separaten Threads ausgeführt wird. Wenn Sie eine solche Aufgabe erstellen, sollten Sie immer wissen, welcher Thread-Pool sie ausführt und was passiert, wenn ein solcher Pool überläuft.

Alle Arbeiten mit Dateien und Verzeichnissen müssen über Try-with-Ressourcen erfolgen. Wenn Sie in einer normalen Anwendung vergessen haben, einen Stream oder eine Datei zu schließen, ist das ein Problem? Es schließt sich selbst, wenn Sie das Programm beenden. Aber wenn Sie irgendwo im Code vergessen haben, eine Datei auf dem Server zu schließen, und Ihr Server seit Monaten läuft ... Bald werden sich Tausende solcher nicht geschlossenen Dateien ansammeln und das Betriebssystem wird aufhören, neue Dateien zum Lesen (Arbeiten mit Dateien) zu öffnen wird vom Betriebssystem gesteuert). Teamlead wird Ihnen nicht auf den Kopf klopfen ...

1.4 Client-Server-Architektur

ein weiterer wichtiger Punkt. Die Client-Server-Architektur definiert lediglich die allgemeinen Prinzipien der Interaktion zwischen Computern , die Details der Interaktion werden durch verschiedene Protokolle bestimmt.

Dieses Konzept (Client-Server) sagt uns, dass wir die Maschinen im Netzwerk in Client-Maschinen, die immer etwas benötigen, und Server-Maschinen, die geben, was sie brauchen, unterteilen müssen. In diesem Fall startet der Client immer die Interaktion und die Regeln, nach denen die Interaktion stattfindet, werden durch das Protokoll beschrieben.

Es gibt zwei Arten von Client-Server-Interaktionsarchitekturen: Die erste wird als zweischichtige Client-Server- Architektur bezeichnet, die zweite als mehrschichtige Client-Server-Architektur (manchmal auch als dreischichtige Architektur oder dreischichtige Architektur bezeichnet). aber das ist ein Sonderfall).

Das Funktionsprinzip der zweistufigen Architektur der Client-Server-Interaktion besteht darin, dass die Verarbeitung einer Anfrage auf einem Server erfolgt, ohne dass bei dieser Verarbeitung auf andere Server zurückgegriffen wird.

Das zweistufige Client-Server-Interaktionsmodell kann als einfaches Diagramm dargestellt werden.

Hier sieht man, dass die erste Ebene alles ist, was den Client betrifft, und die zweite Ebene alles ist, was den Server betrifft.