Die grundlegenden Architekturkonzepte die jeder Webentwickler von Anfang an verstehen sollte.

Webarchitektur

Webarchitektur

Einleitung

Das obige Diagramm ist eine ziemlich gute Darstellung einer Web-Architektur. Wenn du kein erfahrener Web-Entwickler bist, wird es wahrscheinlich kompliziert für dich sein. Der Durchlauf unten sollte die Annäherung erleichtern, bevor wir in die Details der einzelnen Komponenten eintauchen.

Als Nächstes führe ich dich durch jede Komponente und führe eine Einführung, die ein gutes Denkmodell für das zukünftige Durchdenken der Webarchitektur geben sollte.

1. DNS

DNS steht für „Domain Name System“ und ist eine Backbone-Technologie, die das World Wide Web ermöglicht. Auf der einfachsten Ebene bietet DNS eine Schlüssel- / Wertsuche von einem Domänennamen (z. B. amazon.com) an und eine IP-Adresse (z. B. 176.32.98.166), die erforderlich ist, damit Ihr Computer eine Anfrage an die entsprechende Adresse weiterleiten kann. Analog zu Telefonnummern ist der Unterschied zwischen einem Domänennamen und einer IP-Adresse der Unterschied zwischen „Hans Meier anrufen“ und „+49 03783993 anrufen“. So wie du früher ein Telefonbuch brauchtest, um Max Nummer abzurufen, benötigst du DNS, um die IP-Adresse einer Domäne zu ermitteln. Du kannst dir also DNS als das Telefonbuch für das Internet vorstellen.

2. LoadBalancer

Bevor wir uns eingehender mit dem LoadBalancer befassen, müssen wir einen Schritt zurückgehen, um die horizontale oder vertikale Anwendungsskalierung zu diskutieren. Was sind sie und was ist der Unterschied? Horizontale Skalierung bedeutet, dass Sie skalieren, indem Sie Ihrem Ressourcenpool mehr Maschinen hinzufügen, während „vertikale“ Skalierung bedeutet, dass Sie skalieren, indem Sie einer vorhandenen Maschine mehr Leistung hinzufügen (z. B. CPU, RAM).

In der Webentwicklung möchte man (fast) immer horizontal skalieren, weil die Dinge einfach zu halten sind. Server stürzen zufällig ab. Netzwerke werden abgebaut. Gelegentlich gehen ganze Rechenzentren offline. Wenn du mehr als einen Server hast, kannst du die Ausfälle planen, damit deine Anwendung weiter ausgeführt werden kann. Mit anderen Worten, deine App ist „fehlertolerant“. Zweitens kannst du mit der horizontalen Skalierung verschiedene Teile deines Anwendungs-Backends (Webserver, Datenbank, Dienst XY usw.) minimal koppeln, indem du beide auf verschiedenen Servern ausführen lässt. Schließlich kannst du eine Skala erreichen, bei der eine vertikale Skalierung nicht mehr möglich ist. Es gibt keinen Computer auf der Welt, der groß genug ist, um alle Berechnungen deiner App durchzuführen. Betrachte die Suchplattform von Google als ein grundlegendes Beispiel, obwohl dies für Unternehmen mit viel kleineren Maßstäben gilt. Es wäre schwierig, diese gesamte Rechenleistung über die vertikale Skalierung bereitzustellen.

Was ist nun der Loadbalancer (Lastenausgleich)? Sie sind die magische Sauce, die eine horizontale Skalierung ermöglicht. Sie leiten eingehende Anforderungen an einen der vielen Anwendungsserver weiter, die in der Regel Klone bzw. Spiegelbilder voneinander sind und senden die Antwort vom App-Server an den Client zurück. Jeder von ihnen sollte die Anforderung auf dieselbe Weise verarbeiten, sodass es nur eine Frage der Verteilung der Anforderungen auf die Server ist, sodass keine von ihnen überlastet wird.

 

3. Webanwendungsserver

Auf High Level sind Webanwendungsserver relativ einfach zu beschreiben. Sie führen die Kerngeschäftslogik aus, die eine Benutzeranforderung bearbeitet und HTML an den Browser des Benutzers zurücksendet. Um ihre Arbeit zu erledigen, kommunizieren sie normalerweise mit einer Vielzahl von Back-End-Infrastrukturen wie Datenbanken, Caching-Schichten, Job-Warteschlangen, Suchdiensten, anderen Mikrodiensten, Daten- / Protokollierungs-Warteschlangen und mehr. Wie oben erwähnt, müssen Sie in der Regel mindestens zwei und oftmals viel mehr an einen Lastverteiler (LoadBalancer) anschließen, um Benutzeranforderungen zu verarbeiten.

App Server-Implementierungen erfordern die Auswahl einer bestimmten Sprache (Javascript (Node.js), Ruby, PHP, Scala, Java, C # .NET usw.) und ein Web-MVC-Framework für diese Sprache (Express für Node.js, Ruby on Rails. CakePHP oder Laravel) erfordern.

4. Datenbankserver

Jede moderne Webanwendung verwendet eine oder mehrere Datenbanken, um Informationen zu speichern. Datenbanken bieten Möglichkeiten zur Definition Ihrer Datenstrukturen, zum Einfügen neuer Daten, zum Suchen vorhandener Daten, zum Aktualisieren oder Löschen vorhandener Daten, zum Durchführen von Berechnungen über die Daten hinweg und mehr. In den meisten Fällen sprechen die Web-App-Server ebenso wie die Jobserver direkt mit einem Server. Darüber hinaus verfügt jeder Backend-Service möglicherweise über eine eigene Datenbank, die vom Rest der Anwendung isoliert ist.

SQL steht für „Structured Query Language“ und wurde in den 70er Jahren entwickelt, um eine standardisierte Methode zur Abfrage relationaler Datensätze bereitzustellen, die einem breiten Publikum zugänglich war. In SQL-Datenbanken werden Daten in Tabellen gespeichert, die über allgemeine IDs (normalerweise Ganzzahlen) miteinander verbunden sind.

NoSQL steht für „Non-SQL“ und ist eine neuere Reihe von Datenbanktechnologien, die sich für die Verarbeitung riesiger Datenmengen eignet, die von umfangreichen Webanwendungen erzeugt werden können (die meisten SQL-Varianten skalieren nicht sehr gut horizontal und kann nur vertikal bis zu einem bestimmten Punkt skaliert werden). Wenn du noch nie etwas von NoSQL gehört hast, empfehle ich, mit einigen hochkarätigen Einführungen wie diesen zu beginnen:

https://www.w3resource.com/mongodb/nosql.php
http://www.kdnuggets.com/2016/07/seven-steps-understanding-nosql-databases.html
https://resources.mongodb.com/getting-started-with-mongodb/back-to-basics-1-introduction-to-nosql

 

5. Caching Service

Ein Caching-Service stellt einen einfachen Schlüssel- / Wert-Datenspeicher bereit, mit dem Informationen gespeichert und nachgeschlagen werden können. In der Regel nutzen Anwendungen Zwischenspeicherungsdienste, um die Ergebnisse teurer Berechnungen zu speichern, sodass die Ergebnisse aus dem Cache abgerufen werden können, anstatt sie beim nächsten Mal neu zu berechnen. Eine Anwendung kann die Ergebnisse einer Datenbankabfrage, Aufrufe von externen Diensten, HTML für eine bestimmte URL und vieles mehr zwischenspeichern. Hier einige Beispiele aus realen Anwendungen:

Google speichert die Suchergebnisse für häufige Suchanfragen wie „Trump“ oder „Bitcoin“ im Cache, anstatt sie jedes Mal neu zu berechnen
Facebook speichert einen Großteil der Daten, die Sie beim Einloggen sehen, wie beispielsweise Blogdaten, Freunde usw.,.

6. Jobwarteschlange und Server

Die meisten Webanwendungen müssen im Hintergrund asynchron arbeiten, was nicht direkt mit der Beantwortung einer Benutzeranfrage zusammenhängt. Zum Beispiel muss Google das gesamte Internet crawlen und indizieren, um Suchergebnisse anzuzeigen. Dies geschieht nicht bei jeder Suche. Stattdessen durchsucht es das Web asynchron und aktualisiert die Suchindizes auf dem Weg.

Zwar gibt es verschiedene Architekturen, die asynchrone Arbeit ermöglichen, aber die allgegenwärtigste ist, was ich die „Job-Warteschlangen“ -Architektur nenne. Sie besteht aus zwei Komponenten: einer Warteschlange mit „Jobs“, die ausgeführt werden müssen und einem oder mehreren Jobservern (häufig als „Worker“ bezeichnet), die die Jobs in der Warteschlange ausführen.

Auftragswarteschlangen speichern eine Liste von Aufträgen, die asynchron ausgeführt werden müssen. Die einfachsten sind FIFO-Warteschlangen (First-In-First-Out), obwohl die meisten Anwendungen eine Art Warteschlangen-Prioritätssystem benötigen. Wenn für die App ein Job ausgeführt werden muss, entweder nach einem bestimmten Zeitplan oder gemäß den Benutzeraktionen, fügt sie der Warteschlange einfach den entsprechenden Job hinzu.

Jobserver verarbeiten Jobs. Sie fragen die Auftragswarteschlange ab, um festzustellen, ob zu erledigende Arbeit besteht, und wenn ja, wird ein Auftrag aus der Warteschlange genommen und ausgeführt. Die zugrunde liegenden Sprachen und Frameworks sind so zahlreich wie bei Webservern, daher werde ich in diesem Artikel nicht auf Details eingehen.

7. Volltextsuchdienst

Viele, wenn nicht die meisten Web-Apps, unterstützen eine Suchfunktion, bei der ein Benutzer eine Texteingabe (häufig als „Abfrage“ bezeichnet) vornimmt und die App die „relevantesten“ Ergebnisse liefert. Die Technologie für diese Funktionalität wird normalerweise als „Volltextsuche“ bezeichnet. Dabei wird ein invertierter Index verwendet, um Dokumente, die die Suchschlüsselwörter (Keywords) enthalten, schnell zu durchsuchen.

Es ist zwar möglich, die Volltextsuche direkt aus einigen Datenbanken durchzuführen (z. B. unterstützt MySQL die Volltextsuche), es ist jedoch üblich, einen separaten „Suchdienst“ auszuführen, der den invertierten Index berechnet und speichert und eine Abfrage-Schnittstelle bereitstellt. Die beliebteste Volltextsuchplattform ist heute Elasticsearch. Es gibt jedoch auch andere Optionen wie Sphinx oder Apache Solr.

8. Services

Sobald eine App einen bestimmten Umfang erreicht, gibt es wahrscheinlich bestimmte „Dienste“, die als separate Anwendungen ausgeführt werden. Sie sind nicht der Außenwelt ausgesetzt, aber die App und andere Dienste interagieren mit ihnen.

9. Daten

Heute leben und sterben Unternehmen, je nachdem, wie gut sie Daten nutzen. Fast jede App, die eine bestimmte Skala erreicht hat, nutzt eine Datenpipeline, um sicherzustellen, dass Daten gesammelt, gespeichert und analysiert werden können.

Eine typische Pipeline besteht aus drei Hauptstufen:

Die App sendet Daten, in der Regel Ereignisse über Benutzerinteraktionen, an die Daten „Firehose“ (Amazon Kinesis Data Firehose), die eine Streaming-Schnittstelle zum Einlesen und Verarbeiten der Daten bereitstellt. Oft werden die Rohdaten transformiert oder erweitert und an einen anderen „Firehose“ übergeben. AWS Kinesis und Kafka sind die zwei gebräuchlichsten Technologien für diesen Zweck.
Die Rohdaten sowie die endgültigen transformierten / erweiterten Daten werden im Cloud-Speicher gespeichert. AWS Kinesis bietet eine Einstellung namens „Firehose“, mit der das Speichern der Rohdaten auf dem Cloud-Speicher (S3) extrem einfach zu konfigurieren ist.
Die transformierten / erweiterten Daten werden häufig zur Analyse in ein Data Warehouse geladen. Wir verwenden AWS Redshift sowie einen großen und wachsenden Teil der Startup-Welt, obwohl größere Unternehmen häufig Oracle oder andere proprietäre Warehouse-Technologien verwenden. Wenn die Datensätze groß genug sind, ist möglicherweise eine Hadoop-ähnliche NoSQL MapReduce-Technologie für die Analyse erforderlich.
Ein weiterer Schritt, der nicht im Architekturdiagramm dargestellt ist: Laden von Daten aus den Betriebsdatenbanken der App und der Dienste in das Data Warehouse. 

10. Cloud-Speicher

„Cloud-Speicher ist eine einfache und skalierbare Methode, um Daten über das Internet zu speichern, darauf zuzugreifen und sie gemeinsam zu nutzen“, so AWS. Du kannst es verwenden, um mehr oder weniger auf das zu speichern, was du in einem lokalen Dateisystem gespeichert haben möchtest, mit dem Vorteil, dass du über eine RESTful-API über HTTP mit ihm interagieren kannst. Das S3-Angebot von Amazon ist bei weitem der beliebteste Cloud-Speicher, der derzeit auf dem Markt erhältlich ist. 

11. CDN

CDN steht für „Content Delivery Network“ (Content Delivery Network) und die Technologie bietet eine Möglichkeit, Assets wie statisches HTML, CSS, Javascript und Bilder über das Web bereitzustellen, viel schneller als die Bereitstellung über einen einzigen Ursprungsserver. Es verteilt die Inhalte auf viele „Edge“ -Server auf der ganzen Welt, sodass Benutzer Assets von den „Edge“ -Servern anstelle des Ursprungsservers herunterladen. In der Abbildung unten fordert ein Benutzer in Spanien beispielsweise eine Webseite von einer Site mit Ursprungsservern in NYC an. Die statischen Assets für die Seite werden jedoch von einem CDN-Edge-Server in England geladen, wodurch viele langsame, transatlantische HTTP-Verbindungsanfragen verhindert werden.

Disclaimer: Der Autor/Sprecher übernimmt keinerlei Gewähr für die Aktualität, Korrektheit, Vollständigkeit oder Qualität der bereitgestellten Informationen. Haftungsansprüche gegen den Verfasser, welche sich auf Schäden materieller oder ideeller Art beziehen, die durch die Nutzung der dargebotenen Informationen bzw. durch die Nutzung fehlerhafter und unvollständiger Informationen verursacht wurden, sind grundsätzlich im weitest zulässigen Rahmen ausgeschlossen. Der Artikel bzw. das Video stellt in keiner Art und Weise eine professionelle Anlage-, Investitions-, Vermögens-, Steuerberatung dar und ersetzt diese auch nicht. In diesem Artikel bzw. das Video werden keine Garantien oder Versprechungen zu Gewinnen gemacht. Alle Aussagen in diesem und anderen Artikel bzw. Video auf Bitfantastic.com und über den dazugehörigen Youtube Kanal entsprechen meiner subjektiven Meinung. Bitfantastic.com ist eine Informationsplattform zur innovativen Blockchain-Technologie. Aufgezeigt werden Anwendungsfälle, Vorteile, Nachteile, Kritische Betrachtungen, Ökonomische und Wirtschaftliche Auswirkungen sowie Chancen und Risiken für die Gesellschaft. Kryptowährungen sind nicht gleich Blockchain! Die Schöpfung virtueller Währungseinheiten (Kryptowährungen) erfolgt im Gegensatz zu den Währungen der Noten- und Geschäftsbanken über private Computernetzwerke. Eine Idee der nichtstaatlichen Ersatzwährung. (laut BaFin) Es handelt sich um höchst spekulative Vorgänge mit der Möglichkeit des Totalverlustes! 

 

Findest du diesen Artikel hilfreich?
[Gesamt: 1 Durchschnitt: 5]

Schreibe einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Pflichtfelder sind mit * markiert.

Beitragskommentare