Back-End-Architekturen für inhaltsorientierte Back-Ends von Webanwendungen

Die Back-End-Architektur bezieht sich darauf, wie Ihr Webanwendungs-Back-End strukturiert ist. Die Back-End-Architektur bestimmt, wie Teile der Anwendung miteinander kommunizieren, um eingehende Anfragen zu verarbeiten und Antworten zu erstellen. Wählen Sie beim Erstellen einer Webanwendung eine Back-End-Architektur aus, die auf Ihren spezifischen Anforderungen und Faktoren basiert, einschließlich der Kosten (sowohl kontinuierlicher als auch umfangreicher), der Komplexität Ihrer Anwendung, Skalierungsziele und der Kompetenz Ihres Teams.

Insbesondere bei inhaltsorientierten Webanwendungen wie E-Commerce, Zeitungen oder Blogs gelten die Konsistenz Ihrer Daten und die Leistungsfähigkeit als kritische Anforderungen. Dies gilt insbesondere, wenn Ihre Anwendung global wächst und sich möglicherweise stärker verteilt. Bei inhaltsorientierten Webanwendungen ist der von Ihrer Anwendung verwendete Datenspeicher ebenfalls von entscheidender Bedeutung. Er wird im Leitfaden zur Datenspeicherung ausführlicher erläutert. Bei der Leistungsoptimierung Ihrer Anwendung ist es von entscheidender Bedeutung, über die üblichen Anwendungsarchitekturen hinauszugehen und Inhalte zu hosten und zugänglich zu machen. Weitere Informationen zur Auswahl der richtigen Hostingstrategie und zur Optimierung deiner App findest du im Hosting-Leitfaden.

Wenn Sie bereits ein Back-End für eine Webanwendung haben, sollten Sie die Grenzen Ihrer aktuellen Architektur berücksichtigen. Wenn Ihre Anwendung beispielsweise skaliert wird und die Anforderungen an Leistung und Zuverlässigkeit steigen, überlegen Sie, ob Teile Ihrer Anwendung refaktoriert oder in eine andere Architektur verschoben werden sollten, die besser für Ihre größere Skalierung geeignet ist. Mit Hybrid- oder Multi-Cloud-Architekturen können Sie beispielsweise einige Arbeitslasten in die Cloud verschieben, bevor Sie eine vollständige Umstellung vornehmen. Die Berücksichtigung der Kosten, der Zeit und des Risikos, die mit einer solchen Migration verbunden sind, ist ebenfalls von entscheidender Bedeutung.

Monolithische Architekturen

Eine monolithische Architektur hat eine einheitliche Struktur, bei der alle Komponenten der Anwendung eng in einer einzigen Codebasis integriert sind. Die gesamte Anwendung wird als einzelne, eigenständige Einheit erstellt. Die monolithische Architektur ist mehrschichtig, wobei verschiedene Ebenen der Anwendung bestimmte Aufgaben ausführen.

Strukturebenen

• Die Benutzeroberfläche, die Komponenten zur Darstellung der Funktionen der Anwendung enthält, ist in der Regel eine webbasierte oder Desktopanwendung, die mit Nutzern interagiert.
• In der Anwendungslogik befindet sich die Hauptfunktion.Dieser Teil der Codebasis enthält die Regeln, Berechnungen und Vorgänge, die die Funktionsweise der Anwendung definieren.
• Die Datenzugriffsebene enthält Funktionen zum Lesen und Schreiben von Daten sowie zum Übersetzen zwischen den Datenstrukturen der Anwendung und dem Datenbankschema. Diese Ebene ist für die Interaktion mit der Datenbank oder dem Datenspeicher der Anwendung verantwortlich.
• In der Datenbank werden die Daten der Anwendung gespeichert. Üblicherweise wird eine einzelne Datenbank verwendet, in der alle Anwendungsdaten, einschließlich Nutzerdaten, Konfigurationen und sonstiger Informationen, gespeichert werden.
• Middleware-Komponenten übernehmen Aufgaben wie Authentifizierung, Anfragerouting und Datenvalidierung. Diese Komponenten helfen bei der Verwaltung des Datenflusses und der Anfragen.
• Einige monolithische Anwendungen haben Integrationspunkte mit externen Diensten oder APIs. Über diese Punkte kann die Anwendung mit Diensten, Datenquellen oder anderen Systemen von Drittanbietern interagieren.

Die Strukturebenen sind normalerweise Teil einer einzigen Codebasis. Diese Codebasis enthält die gesamte Anwendung und ist normalerweise in Verzeichnisse, Module und Klassen organisiert. Entwickler arbeiten an verschiedenen Teilen der Codebasis, um die Anwendung zu erstellen und zu pflegen. Allerdings wird die gesamte Anwendung normalerweise als eine Einheit bereitgestellt. Bei Aktualisierungen oder Änderungen wird die gesamte Anwendung noch einmal bereitgestellt.

Mögliche Herausforderungen

• Mit dem Wachstum monolithischer Anwendungen wird die Codebasis tendenziell komplex und schwerer zu verwalten. Dies kann zu langen Entwicklungszyklen und Schwierigkeiten beim Verständnis der gesamten Codebasis führen.
• Das Bereitstellen von Änderungen an einer monolithischen Anwendung kann riskant sein, da Änderungen an einem Teil des Codes unbeabsichtigt andere Teile der Anwendung beeinflussen können. Dies kann zu einem langwierigen und fehleranfälligen Bereitstellungsprozess führen.
• Monolithische Anwendungen können schwierig zu skalieren sein, da sie als eine Einheit bereitgestellt werden. Sie müssen die gesamte Anwendung skalieren, auch wenn nur eine Komponente einer erhöhten Nachfrage gerecht wird.
• Monolithische Anwendungen beruhen oft auf einem einzigen Technology Stack oder einer einzigen Programmiersprache. Daher ist es möglicherweise begrenzt, das beste Tool für eine bestimmte Aufgabe innerhalb der Anwendung zu verwenden.
• Auch in Zeiten geringer Nachfrage benötigen monolithische Anwendungen erhebliche Ressourcen für den Betrieb. Mit zunehmendem Alter der Anwendung steigen auch die Wartungskosten, da es schwieriger wird, die Anwendung zu aktualisieren und zu patchen, ohne dass Regressionen entstehen.
• Entwicklungsteams, die an monolithischen Anwendungen arbeiten, sind oft rund um die gesamte Anwendung organisiert. Dies führt zu größeren Teams und einer komplexeren Koordination unter den Teammitgliedern.

Empfohlene Verwendung

Monolithische Architekturen sind geeignet, wenn eine Anwendung nur mit moderaten Anforderungen arbeitet und das Entwicklungsteam klein ist. Mit zunehmender Komplexität und Skalierung einer Anwendung oder wenn verschiedene Teile der Anwendung unterschiedliche Technologie oder Bereitstellungsstrategien erfordern, können monolithische Architekturen weniger flexibel und schwieriger zu verwalten werden.

Sie können virtuelle Maschinen erstellen und verwalten, auf denen monolithische Anwendungen in Compute Engine ausgeführt werden können. Sie haben die volle Kontrolle über die Betriebssysteme, die Software und die Verwaltung dieser virtuellen Maschinen, um Ihre monolithische Anwendung auszuführen.

Mit einem Platform-as-a-Service-Dienst wie App Engine können Sie Ihre Anwendung erstellen und in einer vollständig verwalteten Infrastruktur ausführen, die automatisch mit Anfragen skaliert wird.

Wenn Ihre monolithische Anwendung containerisiert ist, können Sie sie mit Google Kubernetes Engine (GKE) oder Cloud Run ausführen. Dienste wie Cloud SQL oder Cloud Spanner können zum Speichern von Daten für monolithische Anwendungen verwendet werden. Sie können basierend auf den spezifischen Anforderungen Ihrer Anwendung eine Kombination aus Diensten und Systemen in Betracht ziehen.

Serverlose Architekturen

Mit der serverlosen Architektur können Sie Anwendungen erstellen und ausführen, ohne physische oder virtuelle Server verwalten zu müssen. Der Cloud-Anbieter verwaltet automatisch die Infrastruktur, Skalierung und Ressourcenzuweisung, sodass sich die Entwickler auf das Schreiben des Codes für ihre Anwendungen konzentrieren können. Serverlose Architekturen können die Entwicklung vereinfachen, den operativen Aufwand reduzieren und die Kosten optimieren, da keine Server gewartet werden muss. Sie eignen sich gut für Mikrodienste, Echtzeit-Datenverarbeitung, Webanwendungen mit variablen Arbeitslasten und Ereignisverarbeitung.

Ereignisbasierte serverlose Architekturen

Ereignisbasierte serverlose Architekturen sind eine spezielle Architektur für serverloses Computing, die auf Ereignissen oder Triggern basiert, um die Ausführung von Funktionen oder Mikrodiensten zu initiieren. Systemkomponenten kommunizieren über Ereignisse und Funktionen werden als Reaktion auf die Ereignisse aufgerufen. Sie verlassen sich häufig auf eine asynchrone Kommunikation, da Funktionen durch Ereignisse ausgelöst und dann unabhängig verarbeitet werden. Unter Umständen erzeugen sie Ereignisse, die dann nachfolgende Aktionen auslösen. Diese Art serverloser Architektur eignet sich gut zum Erstellen skalierbarer, responsiver und lose gekoppelter Systeme.

Mit Google Cloud Functions und Cloud Functions for Firebase können Sie ereignisgesteuerte Funktionen in einer vollständig verwalteten und serverlosen Umgebung erstellen und bereitstellen. Damit können Sie Code als Reaktion auf verschiedene Ereignisse und Trigger ausführen, einschließlich HTTP-Anfragen, Cloud Pub/Sub-Nachrichten, Google Cloud Storage-Änderungen und Firebase Realtime Database-Updates, ohne die Infrastruktur verwalten zu müssen. Zu den Hauptfunktionen gehören Unterstützung in mehreren Sprachen, Skalierbarkeit, detaillierte Abrechnung, Integrationen von Drittanbietern, robustes Logging und Monitoring sowie Einbindung in andere Google- und Firebase-Dienste.

Serverlose Architekturen können für viele Anwendungsfälle kostengünstig sein, insbesondere für Anwendungen mit unterschiedlichen Arbeitslasten, schnellen Entwicklungsanforderungen und unvorhersehbarem Traffic. Die Zuverlässigkeit hängt vom Cloud-Anbieter mit Service Level Agreements (SLAs) ab, um bestimmte Leistungs- und Zuverlässigkeitsziele sicherzustellen. Sie müssen Ihren speziellen Anwendungsfall und Ihre Anforderungen prüfen, um festzustellen, ob eine serverlose Architektur die beste Option ist.

Containerisierung

Mit der Containerisierung können Anwendungen und ihre Abhängigkeiten in leichte, portable Container verpackt werden. Sie bieten eine einheitliche Anwendungsumgebung, die die Entwicklung und Bereitstellung auf verschiedenen Systemen und Plattformen unterstützt. Einige serverlose Plattformen bieten die Möglichkeit, containerisierte Arbeitslasten auszuführen. Das Ausführen von Containern in einer serverlosen Umgebung kann von Vorteil sein, wenn Sie komplexe oder zustandsorientierte Arbeitslasten haben, die nicht als grundlegende Funktionen dargestellt werden können. Sie bietet Flexibilität in Bezug auf Sprachunterstützung und Laufzeitumgebungen.

Cloud Run ist eine serverlose Computing-Plattform, mit der Entwickler Containeranwendungen in einer vollständig verwalteten Umgebung bereitstellen und ausführen können. Sie bietet eine einfache Möglichkeit, Anwendungen zu erstellen, bereitzustellen und zu skalieren, ohne die zugrunde liegende Infrastruktur verwalten zu müssen. Sie eignet sich für eine Vielzahl von Web- und Mikrodienstanwendungen, insbesondere für Anwendungen mit variablen Arbeitslasten, bei denen die Containerisierung Vorteile in Bezug auf Paketerstellung und Konsistenz von Anwendungen bietet.

Mikrodienstarchitekturen

Anwendungen werden in kleine Teile unterteilt, die lose miteinander verknüpft sind und verschiedene Merkmale oder Funktionen implementieren. Diese Dienste können über asynchrone Nachrichten, ereignisbasierte Kanäle oder direkt durch Freigeben einer Schnittstelle kommunizieren. Jeder Dienst wird unabhängig in seinem Container entwickelt, getestet und skaliert, der häufig über einen Orchestrierungsdienst wie Kubernetes verwaltet oder mit einer verwalteten Plattform wie Cloud Run bereitgestellt wird.

Mikrodienstbereitstellungen nutzen in der Regel auch das serverlose Anwendungsparadigma, da sie nicht auf einen zentralen Server angewiesen sind.

Das Aufteilen einer Anwendung in autonome Dienste kann ein komplexes System vereinfachen. Klar definierte Grenzen und Ziele können die Entwicklung beschleunigen und die Wartung verbessern. Jeder Mikrodienst kann unabhängig mit den effektivsten Frameworks oder Tools entwickelt werden. Die Kommunikation zwischen Diensten wird häufig über Ereignisse, die Publish-Subscribe-Kommunikation, Nachrichtenpipelines oder Remote-Prozeduraufrufe wie gRPC abgewickelt.

Erwägen Sie für die Orchestrierung von Aufgaben innerhalb einer Mikrodienstarchitektur die Verwendung eines Frameworks, das die von Ihnen angestrebten Plattformen unterstützt, genügend Tiefe für die Aufgaben und Workflowtypen, die Sie orchestrieren, sowie Fehlerbehandlung und Telemetrie zum Beheben von Problemen. Beliebte Tools sind Conductor oder Angebote eines Cloud-Anbieters wie Google Workflows.

Die Entwicklung und Wartung von Mikrodienst-Anwendungen kann aufgrund ihrer verteilten Natur und der Notwendigkeit einer dienstinternen Kommunikation komplex sein. Daher sind Verwaltung von Bereitstellungen, Monitoring und Logging komplexer als andere Architekturoptionen. Da die Zuverlässigkeit von der Architektur der einzelnen Dienste abhängt, kann die verteilte Natur zusätzliche Ausfallsicherheit bieten, insbesondere wenn Monitoring und Telemetrie bereitgestellt und bei Bedarf aktiviert werden.

Vergleich verschiedener Architekturen für inhaltsorientierte Web-App-Back-Ends

In der folgenden Tabelle werden Architekturen mit den wichtigsten Anforderungen für das Back-End einer inhaltsorientierten Webanwendung verglichen.

	Monolithische Architekturen	Serverlose, ereignisbasierte Architekturen	Serverlose Mikrodienstarchitekturen
Komplexität und Wartung	Einfache Implementierung für kleine, in sich geschlossene Projekte, aber die Komplexität steigt mit dem Maßstab. Erfordert manuelle Wartung und Koordination.	Die Skalierung wird gut unterstützt und ist in die Plattform integriert. Fehlerbehebung kann eine Herausforderung sein. Keine Infrastrukturverwaltung erforderlich.	In sich geschlossene Dienste, die unabhängig getestet und bereitgestellt werden, um die Wartung der einzelnen Einheiten zu erleichtern. Erfordert eine sorgfältige Kommunikation zwischen Diensten. Erfordert Verwaltungs- und Orchestrierungstools für die Verwaltung in größerem Umfang.
Skalierbarkeit und Leistung	Effizienz in kleinem Maßstab, schwierige Skalierung über eine bestimmte Größe hinaus Spezifische Infrastrukturanforderungen, wodurch die Optionen für die dynamische Skalierung eingeschränkt werden Manuelle Skalierung (oder Verwendung manueller Dienste) innerhalb der Architektur, z. B. durch Load-Balancing.	Integrierte Skalierbarkeit durch die Nutzung einer verwalteten Plattform. Skalierung in beide Richtungen.	Jeder Dienst ist auf einen bestimmten Bedarf zugeschnitten und kann unabhängig skaliert und optimiert werden.
Ausfallsicherheit und Fallback-Strategien	Die Bereitstellung ist komplex und kann zu Ausfallzeiten führen.	Gehört dem Cloud-Anbieter. Jede unabhängige Funktion kann unabhängig wiederholt werden.	Jeder Dienst ist eigenständig, wodurch das Gesamtsystem durch unabhängige Tests und Entwicklungen widerstandsfähiger wird.
Entwicklungserfahrung	Schnelle Entwicklung in kleinem Maßstab durch enge Kopplung der Architektur (z. B. durch effiziente Abfragen). Lange Build-Zeiten und schwierige Zusammenarbeit und Tests, wenn die Komplexität zunimmt.	Es muss keine Infrastruktur gewartet und verwaltet werden, was die Entwicklung beschleunigt. Das Testen und Debuggen einer Live-Anwendung hängt von den Diensten des Cloud-Anbieters ab.	Dienste sind in sich geschlossen und können unabhängig voneinander entwickelt werden. Eine große Anzahl von Diensten muss koordiniert und verwaltet werden.
Kosten	Eine komplexe Entwicklung kann zu höheren Kosten führen. Erfordert insbesondere in größerem Umfang erhebliche Investitionen in Hardware oder Infrastruktur. Kosteneffizienzen durch Hoch- und Herunterskalieren sind schwer zu realisieren.	Keine Kosten für dedizierte Hardware. Hoch- und herunterskalieren, um Ressourcennutzung und -kosten zu optimieren (auf null)	Keine Kosten für dedizierte Hardware. Hoch- und herunterskalieren, um Ressourcennutzung und Kosten innerhalb von Grenzen zu optimieren Zusätzliche Kosten durch die Überwachung und Verwaltung einer großen Reihe unabhängiger Dienste.

Weitere Informationen zu Back-End-Architekturen für inhaltsorientierte Webanwendungen

Im Folgenden finden Sie einige Ressourcen mit weiteren Informationen zu Architekturen für inhaltsorientierte Webanwendungen. Dort erfahren Sie auch, wie Sie Ihre Anwendung zu einer anderen Architektur migrieren können:

• Weitere Informationen zu lose gekoppelten Back-End-Architekturen für Webanwendungen, einschließlich mehrstufiger monolithischer und serverloser Webanwendungen.

• Monolithische Anwendung zu einer Mikrodienstarchitektur migrieren

• Typische Anwendungsfälle für serverlose Cloud Functions-Funktionen