Einführung in die dreistufige Architektur
Die dreistufige Architektur ist die am weitesten verbreitete Interaktionsarchitektur im Internet. Es entstand, als der zweistufige Serverteil in zwei Teile geteilt wurde: eine Logikschicht und eine Datenschicht .
Es sah ungefähr so aus:
Die Client-Schicht ist der Teil der „verteilten Anwendung“, der für die Benutzerinteraktion verantwortlich ist. Diese Schicht sollte keine Geschäftslogik enthalten und keine kritischen Daten speichern. Außerdem sollte es nicht direkt mit der Datenbankschicht interagieren, sondern nur über die Geschäftslogikschicht.
Allerdings gibt es hier immer noch eine gewisse Logik. Erstens ist dies die Interaktion mit dem Benutzer über die Schnittstelle, die Validierung der von ihm eingegebenen Daten und die Arbeit mit lokalen Dateien. Dazu gehört auch alles rund um die Benutzerautorisierung und Datenverschlüsselung bei der Arbeit mit dem Server.
Zweitens handelt es sich um eine einfache Geschäftslogik. Wenn beispielsweise ein Online-Shop eine Produktliste gesendet hat, können wir diese auf Kundenseite sortieren und filtern. Und hier gibt es auch eine primitive Datenspeicherung: Caching, Cookies für angemeldete Benutzer und dergleichen.
Auf der zweiten Ebene befindet sich die Geschäftslogikschicht , auf der sich der Großteil der Geschäftslogik konzentriert. Außerhalb bleiben nur Fragmente übrig, die an den Client exportiert werden, sowie Logikelemente, die in die Datenbank eingebettet sind (gespeicherte Prozeduren und Trigger).
Ein großer Teil der Geschäftslogik des Servers enthält nicht nur dieselbe Logik, sondern löst auch Skalierungsprobleme: Der Code wird in Teile aufgeteilt und auf verschiedene Server verteilt. Einige stark nachgefragte Dienste können auf Dutzenden von Servern laufen. Die Last zwischen ihnen wird vom Load Balancer verwaltet.
Serveranwendungen sind in der Regel so konzipiert, dass eine andere Kopie des Servers problemlos gestartet und in Zusammenarbeit mit anderen Kopien davon in Betrieb genommen werden kann. Das heißt, selbst beim Schreiben von Servercode haben Sie niemals die Garantie, dass Ihre statische Klasse in einer einzigen Instanz gestartet wird.
Die Datenschicht stellt die Datenspeicherung bereit und ist auf einer separaten Ebene platziert, die in der Regel über Datenbankmanagementsysteme (DBMS) implementiert wird. Die Verbindung zu dieser Komponente erfolgt nur von der Ebene des Anwendungsservers.
Gründe für die Trennung der Datenschicht
Die Trennung der Datenschicht in eine vollwertige dritte Schicht erfolgte aus vielen Gründen, der wichtigste Grund ist jedoch die erhöhte Belastung des Servers.
Erstens benötigten Datenbanken für die Datenverarbeitung viel Speicher und Prozessorzeit. Daher wurden sie überall auf separaten Servern platziert.
Bei erhöhter Auslastung konnte das Backend problemlos dupliziert und zehn Kopien eines Servers erstellt werden, eine Duplizierung der Datenbank war jedoch nicht möglich – die Datenbank blieb weiterhin eine einzige und unteilbare Komponente des Systems.
Zweitens sind Datenbanken intelligent geworden – sie verfügen über eine eigene Geschäftslogik. Sie begannen, gespeicherte Prozeduren, Trigger und ihre eigenen Sprachen wie PLSQL zu unterstützen. Und es erschienen sogar Programmierer, die begannen, Code zu schreiben, der im DBMS ausgeführt wird.
Die gesamte Logik, die nicht an Daten gebunden war, wurde ins Backend verlagert und parallel auf Dutzenden von Servern gestartet. Alles, was kritisch mit den Daten zu tun hat, blieb im DBMS, und bereits dort mussten die Probleme der erhöhten Last mit unseren eigenen Methoden gelöst werden:
- Ein Datenbankcluster ist eine Gruppe von Datenbankservern, die dieselben Daten speichern und diese mithilfe eines bestimmten Protokolls synchronisieren.
- Sharding – Daten werden in logische Blöcke aufgeteilt und auf verschiedene Datenbankserver verteilt. Mit diesem Ansatz ist es sehr schwierig, Datenbankänderungen beizubehalten.
- Der NoSQL-Ansatz besteht darin, Daten in Datenbanken zu speichern, die für die Speicherung großer Datenmengen ausgelegt sind. Dabei handelt es sich häufig nicht einmal um Datenbanken, sondern um konkrete Dateispeicher. Sehr schlechte Funktionalität im Vergleich zu relationalen Datenbanken.
- Daten-Caching. Anstelle eines einfachen Caches auf Datenbankebene erschien ein komplettes Caching-DBMS, das das Ergebnis nur im Speicher speicherte.
Es ist klar, dass für die Verwaltung dieses Zoos an Servertechnologien separate Personen und/oder ganze Teams erforderlich waren, was zur Entfernung der Datenschicht in eine separate Schicht führte.
Wichtig! Alle fortschrittlichen Technologien entstehen in den Tiefen großer IT-Konzerne, wenn alte Ansätze den neuen Herausforderungen nicht mehr gewachsen sind. Die Umwandlung von Datenbanken in eine separate Schicht wurde nicht von irgendeinem Programmierer erfunden, sondern von einer Gruppe von Ingenieuren irgendwo in den Tiefen von Oracle oder IBM.
Interessant! Als Zuckerberg anfing, Facebook zu schreiben, arbeitete er einfach an PHP + MySQL. Als es Millionen von Benutzern gab, schrieben sie einen speziellen Übersetzer, der den gesamten PHP-Code in C++ übersetzte und ihn in nativen Maschinencode kompilierte.
Da MySQL nicht in der Lage ist, die Daten von Milliarden von Benutzern zu speichern, entwickelte Facebook das Konzept der NoSQL-Datenbanken und schrieb ein leistungsstarkes serverseitiges NoSQL-DBMS – Cassandra. Es ist übrigens komplett in Java geschrieben.
Mehrdeutigkeit des Speicherorts der Anwendungslogik
Und obwohl eine dreistufige Architektur die Rollen zwischen ihren Teilen nahezu eindeutig verteilt, ist es nicht immer möglich, genau zu bestimmen, wo im System ein neuer Teil der Geschäftslogik (neuer Code) hinzugefügt werden muss.
Ein Beispiel für eine solche Mehrdeutigkeit ist im Bild unten dargestellt:
Der Serverteil ist mit einem grauen Hintergrund gefüllt, der Clientteil ist mit Weiß gefüllt. Ein gutes Beispiel für den letztgenannten Ansatz (ganz rechts) sind moderne mobile Apps. Die Clientseite (auf dem Telefon) enthält die Ansicht (Anzeige), Logik und Daten. Und nur manchmal werden diese Daten mit dem Server synchronisiert.
Ein Beispiel für die Option ganz links ist ein typischer PHP-Server, der über die gesamte Logik auf dem Server verfügt und dem Client bereits statisches HTML bereitstellt. Irgendwo zwischen diesen beiden Extremen wird Ihr Projekt angesiedelt sein.
Zu Beginn der Arbeit, nachdem Sie sich mit dem Projekt vertraut gemacht haben, müssen Sie sich mit den daran arbeitenden Programmierern darüber beraten, an welchen Stellen Sie die Logik der nächsten Aufgabe besser implementieren können.
Fühlen Sie sich frei, dies zu tun. Erstens steigen sie mit ihrer Urkunde nicht in das Kloster eines anderen ein. Zweitens wird es für alle (und auch für Sie) einfacher sein, den benötigten Code an der Stelle zu finden, an der Sie ihn erwarten.