Get best of the week

Client-Server-Architektur in Bildern



Ein bekanntes Bild? Sie sind jedoch ständig mit dieser Architektur konfrontiert - wenn Sie eine Kinokarte online kaufen, eine Eintrittskarte zum Meer buchen oder einen Termin mit einem Arzt vereinbaren.

Auf der Client-Server-Architektur werden alle Sites und Internetdienste erstellt. Es wird auch von Desktop-Programmen verwendet, die Daten über das Internet übertragen. Daher müssen IT-Experten verstehen, was es ist und wie es funktioniert.

Ich werde darüber im Artikel sprechen. Ich erkläre es an den Fingern mit Beispielen und lustigen Bildern =) Wenn dir das Videoformat besser gefällt, kannst du mein YouTube-Video zum gleichen Thema ansehen .

Inhalt




Was ist das und wie funktioniert es?


Hier haben wir einen gewissen Vasya, der beschlossen hat, ein Auto zu kaufen. Wie in der Werbung - schnell, kraftvoll, schön! Sie steht wie das Heck eines Flugzeugs, Vasya hat nicht so viel Geld.



Natürlich kann Vasya mehrere Jahre lang graben und dann ein Auto kaufen. Aber du willst hier und jetzt! Ja, und ein Fahrzeug wird benötigt ...

Und Vasya weiß nicht, wie man spart - erhielt ein Gehalt, kaufte das Hauptgehalt, bezahlte die Unterkunft, das ist alles! Der Rest kann ausgegeben werden. Für solche Leute gibt es Banken, bei denen Sie kommen und Geld auf Kredit nehmen können.



Natürlich zahlen Sie dann zu viel und geben sie zurück. Interesse ist Pferd. Aber jetzt können Sie es sich schon leisten, etwas Teuereres zu kaufen.

Vasya dachte, schätzte und sagte:

- Ja, ich will es so! Ich kann 100 Rubel von meinem Gehalt an die Bank zahlen, aber ich kann es nicht sparen. Ich werde es ausgeben.

Deshalb geht Vasya zur Bank und sagt:

- Ich bin Vasily Ivanov, ich möchte einen Autokredit für 1000 Rubel.



Der Sachbearbeiter Katya muss seine Bonität überprüfen. Plötzlich kann er keinen Kredit mehr bekommen, hat er eine schlechte Geschichte? Vielleicht hat er schon 10 Credits erzielt und keiner zahlt? Oder vielleicht ist er überhaupt ein Terrorist ?! Es muss überprüft werden, ob die Bediener schwarze Listen nicht auswendig kennen.



Katya hat ein spezielles Programm zur Überprüfung von Kundendaten. Dieses Programm kann entweder Web oder Desktop sein:

  • Web - Öffnen Sie in einem Browser wie Google oder Facebook
  • Desktop - auf einem Computer wie einem Wort oder einem Taschenrechner

Es spielt keine Rolle, ob Katya auf den Browser oder nur auf das Programm schaut. In jedem Fall wird es ein Kunde sein. Der Kunde ist Ihre Anwendung. Der, mit dem unser Operator arbeitet.



Katya fährt das Programm „Vasily Ivanov“ und erhält Informationen über den Kunden - steht er auf der schwarzen Liste? Gab es schon einmal eine Bonitätshistorie? Usw. Aber was passiert in den Innereien der Anwendung?



Katya gab die Daten auf dem Client ein. Aber als sie auf "check" klickte, schickte der Client eine Anfrage an den Server:

- Gib mir Informationen über Vasya Ivanov!



Der Server hat eine Anfrage an die Datenbank gesendet, Datenbank:

- Wählen Sie * von Clients mit fio = 'Vasily Ivanov'. (Geben Sie mir alle Informationen über den Namen 'Vasily Ivanov')



Die Basis antwortete:

- Hier haben Sie alles, was ich gefunden habe.



Der Server hat diese Informationen an den Client zurückgegeben:



Und der Kunde hat es bereits für Katya gezeichnet:



Katya sieht aus:

- Ja, die Bonitätshistorie ist gut.



Und er schlägt Vasya vor:

- Wenn Sie einen Kredit aufnehmen möchten, sind wir bereit, 12 Jahre lang 1000 Rubel zu 80% pro Jahr zuzuteilen. Vereinbart worden?



Vasya freut sich:

- Ja, alles passt zu mir, gib mir mehr Geld und ich rannte dem Auto hinterher!
Jeder ist glücklich, jeder ist glücklich.



Katya weiß nicht einmal, wie die Daten im Programm waren, als sie den vollständigen Namen ihres Kunden dorthin fuhr. Aber Sie und ich müssen herausfinden, was für ein Weg das ist. Und warum all diese Schwierigkeiten? Warum so eine Struktur? Warum gibt es einen Client, warum gibt es einen Server?


Warum brauche ich einen Kunden?



Hier ist alles einfach - der Benutzer arbeitet mit dem Kunden. Es wird benötigt, um die Bytes des Programmcodes in ein schönes und verständliches Bild zu verwandeln. Der Benutzer ist kein Programmierer, er versteht die Programmiersprache oder SQL nicht. Er versteht Formen und Knöpfe. Wir zeichnen sie im Kunden.




Warum brauchen wir einen Server?



Er ist mächtiger. Es

kann viele Kunden geben. Im Beispiel mit der Bank können wir 10 Filialen in 10 Städten Russlands haben, und jede Filiale hat 10 Betriebsagenten. Eintausend Katek, und jeder hat einen separaten Computer.



Wir möchten jedoch, dass die Anwendung schnell funktioniert. Damit es nicht dumm ist und nicht einfriert, den Bediener nervt und den Client warten lässt. Das Auto braucht also ein starkes. Wenn jedoch der Computer jedes Bedieners leistungsfähig ist, müssen Sie viel Geld investieren!

Daher übertragen wir die gesamte Grundlogik auf den Server. Und jetzt machen wir es mächtig! Und Client-Maschinen können billig sein, weil sie nur Logik im Stil von "Informationen anfordern und schön rendern" haben.


Keine Codeduplizierung

Wenn wir nur Client-Maschinen hätten, hätte jeder von ihnen den gleichen Logikverarbeitungscode, die gesamte Datenbank, alle Terroristenverzeichnisse und so weiter. Da der Server und die Datenbank jedoch in getrennten Links angeordnet sind, wird viel Speicherplatz vom Client-Computer freigegeben ... und der Code.

Der Code muss nicht dupliziert werden, da die gesamte Hauptlogik auf einen leistungsstärkeren Server übertragen wird.




Dies ist sicherer.

Auf dem Server und in der Datenbank werden Informationen gespeichert, auf die ein einfacher Bediener nicht zugreifen kann. Das:

  • Kundendaten
  • Informationen über seine Finanzen
  • Bank Blacklists
  • ...

Warum diese Informationen allen und jedem zeigen? Der Bediener sieht nur ihre Schnittstelle. Ich fuhr einen vollständigen Namen - ich bekam eine Antwort, ob ich einen Kredit geben sollte oder nicht. Alle. Sie braucht nichts anderes.

Es gibt Angestellte, die bereit sind, Kundeninformationen für Denyushki zusammenzuführen. Es gibt unehrliche Menschen, die bereit sind, versehentlich über ihre Schultern zu schauen. Oder vielleicht ist der Kunde selbst eine solche Person. Stellen Sie sich vor, Vasya schiebt die zerbrechliche Katya, setzt sich an ihren Computer und überweist Millionen auf ihr Konto, bis es von Wachen gefesselt wird.




Warum brauchen wir eine Basis?


Was hat die Datenbank damit zu tun? Hier haben wir unseren Server, auch wenn er alle Informationen speichert. Es kommt vor, dass die Datenbank manchmal einfach nicht benötigt wird und wir immer noch eine zweistufige Client-Server-Architektur haben.



In diesem Fall speichert der Server alle Daten im Speicher. Aber nur wenn der Server abstürzt oder nur neu startet, gehen alle Informationen verloren. Alles, was sich im Speicher befand, wird beim Ausschalten des Systems gelöscht.

DB (Datenbank) - ein separates Softwareprodukt, mit dem Sie:

  • Informationen schnell abrufen
  • Speichern Sie Informationen auch beim Neustart des Systems.

Das heißt, wenn das Netzwerk plötzlich verschwindet, die Basis einfriert, der Computer mit der Basis neu startet oder etwas anderes passiert, gehen unsere Änderungen nicht verloren. Dies nennt man Persistenz. Dies wird durch Transaktionen erreicht, die zurückgesetzt werden, wenn etwas schief geht. Aber in diesem Artikel werden wir uns nicht mit diesem Thema befassen.))

Ja, es gibt möglicherweise keine Basis. Wenn dies der Fall ist, sind wir von der Sicherheit der Daten überzeugt und können problemlos danach suchen.




Architekturvorteile


Wir fassen die Vorteile der Architektur zusammen:

  1. Ein leistungsstarker Server ist billiger als mehr als 100 leistungsstarke Client-Computer. Wenn die Anwendung nicht langsamer werden soll, benötigen wir einen guten Computer. Du wirst einen haben. Oder ein paar, wenn die Last groß ist, aber deutlich weniger als die Anzahl der Kunden.
  2. — , « » « , 100 ».
  3. — . , .



Eine Verbindung ist

gefallen - alle ruhen sich aus. Wenn der Server gefallen ist oder die Basis heruntergefallen ist, dh eine Verbindung sich verschlechtert hat - alles, jeder ist in einem Zustand der Betäubung, alle ruhen sich aus. Hunderte, Tausende und sogar Millionen von Kunden, wenn überhaupt, kann niemand arbeiten. Alle Operationsoffiziere schauen traurig zum Fenster „Entschuldigung, etwas ist schief gelaufen“ und zucken mit den Händen vor dem Kunden.



Aus diesem Grund ist die Architektur in geschäftskritischer Software kompliziert und sogar dupliziert. Eine Bank mit Tausenden von Kassierern kann sich keine Ausfallzeit leisten. Daher verwenden sie einen Servercluster - einer fiel, der Rest funktioniert.



Wie versteht der Kunde dann, wohin er die Anfrage senden soll?

Vor den Servern befindet sich ein Balancer, über den der Client eine Anfrage sendet. Unabhängig davon, wie viele Server im Cluster gespeichert sind, ist der Client nicht interessiert. Es hat eine URL - die Adresse des Balancers.



Und jetzt erhält der Kunde eine Anfrage:

- Geben Sie mir alle Informationen über Vasya Ivanov.

Der Balancer sagt:

- Leute, eine neue Anfrage! Wer ist weniger beladen?



Erster Server:

- Ich habe 5 Anfragen in der Warteschlange.

Zweitens:

- Und ich habe 2. Der

Balancer sendet eine Anfrage an den zweiten Server.



Ein solches Schema wird für eine hoch ausgelastete Anwendung verwendet - wenn es so viele Anforderungen gibt, dass ein Server diese einfach nicht bewältigen kann.

Facebook, Amazon, Google - Millionen von Nutzern gehen dorthin. Ein Server kann sie nicht verarbeiten. Daher setzen sie einen Cluster und der Balancer teilt die Last zwischen ihnen. In diesem Fall gibt es im Cluster möglicherweise nicht zwei Server, sondern 10, 15, solange wir dies benötigen, setzen wir so viele ein.



Auf diese Weise können wir die Datenbank auf die gleiche Weise ausgleichen. Wir können mehrere Kopien der Datenbanken auf verschiedenen Computern haben, und der Balancer sendet Anforderungen an die eine oder die andere.



Dieses Schema wird als Hot Standby bezeichnet, wenn mehrere Server parallel ausgeführt werden und der Balancer die Last auf diese verteilt.

Es kann auch ein Cold-Reserve- Schema geben - wenn unser zweiter Server ein Backup "nur für den Fall" ist. Alle Anfragen gehen an den ersten Server, der zweite ruht.



Wenn jedoch etwas mit dem ersten Server passiert und dieser stirbt, leitet der Balancer die Last auf den zweiten Server um:





Zu diesem Zeitpunkt haben Administratoren Zeit, sich mit dem Problem auf Server 1 zu befassen.

Das Kühlreserveschema wird verwendet, wenn ein Server der Last standhalten und eine gute Geschwindigkeit liefern kann. Die Anwendung ist jedoch geschäftskritisch und einfach inakzeptabel.

Es kann einfach sein, nicht nur, weil etwas Schlimmes passiert ist. Es gibt auch ein regelmäßiges Anwendungsupdate. Mit beiden Sicherungsschemata können Sie problemlos aktualisieren. Wenn sich zwei Server im Cluster befinden, sieht das Update folgendermaßen aus:

  1. Leiten Sie die gesamte Last auf Server 2 um
  2. Stoppen Sie Server 1
  3. Server aktualisieren 1
  4. Wir starten es und richten die gesamte Ladung darauf
  5. Stoppen Sie Server 2
  6. Aktualisiere es
  7. Wir starten
  8. Teilen Sie die Ladung erneut (wenn es sich um eine heiße Reserve handelt)

Das heißt, die Anwendung hört überhaupt nicht auf zu arbeiten!

Redundanzschemata helfen uns somit, das Problem zu beseitigen, dass "1 Verbindung unterbrochen wurde - alle ruhen sich aus". Der Client wird nie erfahren, dass ein oder mehrere Server im Cluster tot sind, alles für ihn funktioniert hat und es funktioniert. Hochpreisige





Serverausrüstung ist

teuer. Dort kann man keine normale SSD für einen Heimcomputer einsetzen. Warum? Da die Hardwareanforderungen für Server für Hardware + völlig unterschiedlich sind, werden bestimmte Funktionen unterstützt:

- Die Festplatte verfügt über eine spezielle Controller-Firmware, die für den Festplattenbetrieb in RAID optimiert ist. Dies ist zu Hause nicht erforderlich.

- Auf der SSD ist eine Gruppe von Kondensatoren vorhanden, die bei einem Stromausfall Energie speichern, sodass genügend Zeit vorhanden ist, um Daten aus dem DDR-Cache in den nichtflüchtigen Speicher zu werfen, und die Daten nicht brechen.

SSD - eine schnell arbeitende Festplatte, HDD - normal. RAID - wenn wir N Festplatten miteinander verbunden haben und der DDR-Cache RAM ist

Außerdem haben Serverlösungen normalerweise eine viel längere Garantie: 5 Jahre, kein Jahr.




Für den Preis unterscheiden sie sich um das 2-fache. Zum Beispiel SSD:

  • für ein Haus kostet Gigabyte 16,53r
  • für einen Server Enterprise Gig kostet 32 ​​Rubel

Zahlen für Dezember 2019. Dies ist wenn nicht Markeneisen zu nehmen, sondern vom Hersteller.

Es scheint nicht viel anders zu sein, oder? Aber der Punkt ist, dass für ein Haus 1 TB für die Augen ausreicht - und alle Fotos passen und Filme und eine Reihe von Anwendungen ... Und für die Datenbank sind manchmal 10 TB klein. Und wenn Sie einen Cluster erstellen, multiplizieren wir die Kosten mit 2, wenn nicht mehr. Daher scheint der Preisunterschied riesig zu sein, aber wenn er in Gigabyte umgerechnet wird, kommt ein kleiner heraus.

Vergessen Sie nicht, dass Sie zu Hause nur Ihre Fotos aufbewahren müssen, und selbst diese befinden sich normalerweise in der Cloud. Und auf dem Server befindet sich eine geschäftskritische Funktionalität, die viele Ressourcen verbraucht und die dupliziert werden muss, falls "plötzlich der erste stirbt".


Müssen Sie einen Systemadministrator einstellenツ

Wir müssen einen Systemadministrator einstellen, der alle unsere Anwendungsserver und Datenbanken überwacht. Fügen Sie sein Gehalt zu den Ausrüstungskosten hinzu!



Was zu testen


Um zu verstehen, was zu testen ist, müssen Sie verstehen, womit eine Person zu tun hat.

Der Benutzer arbeitet mit einem Client. Es kann eine Web- oder Desktop-Anwendung sein, nicht der Punkt. Die Bedienerin Kate erhielt einen Arbeitsplatz, sie zeigte, welches Programm ausgeführt werden sollte und wie damit gearbeitet werden sollte. Sie weiß nichts über die Verfügbarkeit von Servern und Datenbanken, sie arbeitet nur mit dem Client.



Daher prüft der Tester zuerst den Client! Da der Server perfekt funktionieren kann, können Sie sogar Tests auf API-Ebene schreiben, und alle sind grün, und es scheint, dass jeder verletzt ist! Der Benutzer lädt den Bericht herunter und sieht den Fehler. Oh.

Der Server läuft, auf dem Client ist ein Fehler aufgetreten. Und kümmern Sie sich nicht um Hunderte von "grünen" Autotests. Der Benutzer hat immer noch einen Fehler. Und unsere Aufgabe ist es, aus seiner Sicht zu schauen.



Wenn Sie jedoch Zugriff auf den Anwendungsserver und seine Datenbank haben, sollten Sie diese ebenfalls überprüfen! So können wir den "zukünftigen Fehler" sehen. Zum Beispiel:

  • Wir haben die Produktkarte gespeichert - das System zeichnet sie und sagt, dass alles in Ordnung ist. Auf dem Kunden ist alles in Ordnung!
  • Wir haben die Datenbank überprüft - und da ein Teil der Felder leer blieb, hat der Entwickler den Namen des Feldes in der Datenbank falsch angegeben. Und die Informationen gingen verloren.

Was der Benutzer jetzt im Client sieht, ist nur ein Cache. "Was ich eingegeben habe, ist das, was ich anzeige." Wenn Sie die Datenbank nicht überprüfen, tritt ein solches Problem möglicherweise nicht sofort auf. Der Benutzer öffnet die Produktkarte - einige der Felder sind nicht ausgefüllt:

- Nun, wahrscheinlich wurden sie nicht ausgefüllt.

Und sie waren gefüllt! Nur schief zu sparen hat funktioniert. Wenn wir also nur eine Blackbox haben, müssen wir überprüfen: "Werden die Daten wirklich gespeichert?" Gerettet? Öffnen Sie die Karte in einem neuen Fenster oder rufen Sie die Informationen über die API-Methode auf.

Wenn Sie Zugriff auf die Datenbank haben, überprüfen Sie einfach, ob alles in Ordnung ist. Wenn Sie Zugriff auf Serverprotokolle haben, überprüfen Sie diese auf Fehler.



Neben normalen Benutzern gibt es böse Menschen, die versuchen, in unserer Anwendung zu bleiben und Geld / Daten zu stehlen. Sie verwenden keinen Client oder Server - sie haben dort keinen Zugriff. Sie versuchen, Daten vom Client zum Server oder vom Server zur Datenbank abzufangen.



Wenn schlechte Leute das können, muss der Tester das auch können! Weil der Tester Informationen über unser Produkt liefert.



Der Tester untersucht die Schwachstellen und teilt dem Team dann mit:

- Leute, also habe ich überprüft, ob wir solche und solche potenziellen Lücken haben. Lassen Sie uns darüber nachdenken, ob wir sie irgendwie schließen müssen oder nicht.

Das ist nicht die Tatsache, dass sie das Problem beheben werden. Möglicherweise haben Sie eine unkritische Anwendung - die Daten werden nicht verloren gehen, Sie speichern kein Geld. Dann wird sich niemand mehr darum kümmern, denn Sicherheitstests sind teuer, es gibt nur wenige Spezialisten.

Es lohnt sich jedoch, einige grundlegende Überprüfungen wie SQL-Injektionen oder XSS-Angriffe zu untersuchen und Ihre Anwendung zu überprüfen. Zumindest um ihre Kritikalität zu verstehen. Immerhin, wenn der Angriff den Klienten bricht - nun, lassen Sie sich Pinocchio sein. Und wenn der Angriff den Server setzt, ist es nicht sehr gut. Und man muss zumindest wissen, woraus es passiert.


Gesamt




Der Client ist das Programm, mit dem der Benutzer arbeitet. Er weiß nicht, ob dies das gesamte Programm auf seinem Computer ist oder ob sich irgendwo ein Server mit einer Basis oder sogar einem ganzen RAID dahinter versteckt. Es funktioniert in einem Browser oder mit einer Desktop-Anwendung. Und alles, was er wissen muss, ist, wo er stupsen muss.

Der Client benötigt nicht viel Speicher, Speicherplatz und andere Ressourcen. Daher sind Jobs relativ billig. Und genau das brauchen wir, insbesondere wenn wir Ausrüstung für Tausende von Bankangestellten kaufen müssen.

Server - ein Computer, auf dem die Anwendung selbst gespeichert ist. Alle Codes, alle Logik, alle zusätzlichen Materialien und Nachschlagewerke. Zum Beispiel das FIAS-Adressverzeichnis oder das Verzeichnis der juristischen Personen des Registers der juristischen Personen - sie nehmen auch einen Platz ein, sowohl für sich als auch im Anwendungsspeicher.

Manchmal sagen sie "Anwendungsserver" und "Datenbankserver". Dies ist normal, da der Server tatsächlich nur eine Maschine, ein Computer ist. Aus Sicherheitsgründen werden die Datenbank und der Anwendungsserver normalerweise auf verschiedenen Computern gespeichert. In diesem Fall, wenn sie "Anwendungsserver" sagen, sprechen wir über den zweiten Link unseres Schemas.

Anwendungen sind sehr unterschiedlich. Es sind ressourcenintensiv, sie benötigen viel Speicher und Speicherplatz. Es gibt "Lungen", die sogar auf einem Heimcomputer eingesetzt werden können.

DB (Datenbank) - Data Warehouse. Hier können Sie leicht nach Informationen suchen + sind sicher, dass diese auch dann erhalten bleiben, wenn in der Anwendung etwas kaputt geht.

Wie viel Speicherplatz für die Datenbank benötigt wird, hängt von der Datenmenge ab. Es gibt riesige Stützpunkte in Banken, in denen nur 1 TB vorhanden sein wird. Und es gibt sehr kleine, die Sie auf Ihrem Computer installieren können. Zum Beispiel,XAMPP kann geliefert werden. Und es ist unwahrscheinlich, dass Sie so viele Daten darin speichern, dass Sie keinen Platz für sie haben.

Möglicherweise gibt es keine separate Basis, dann wird die Struktur zweistufig: Client-Server. Und alle!

Das Schema ist an Bedingungen geknüpft, im wirklichen Leben werden wir zumindest mehr Kunden haben. Und wenn die Anwendung stark ausgelastet ist, gibt es mehrere Server und mehrere Datenbanken:



PS - Weitere nützliche Artikel finden Sie in meinem Blog unter dem Tag "Nützlich".

More articles:


All Articles