Gestaffeltes Hybridmuster

Last reviewed 2023-12-14 UTC

Die Architekturkomponenten einer Anwendung können entweder als Frontend oder Backend kategorisiert werden. In einigen Szenarien können diese Komponenten für die Verwendung in verschiedenen Rechenumgebungen gehostet werden. Als Teil des gestaffelten Hybridarchitekturmusters befinden sich die Rechenumgebungen in einer lokalen privaten Rechenumgebung und in Google Cloud.

Frontend-Anwendungskomponenten werden Endnutzern oder Geräten direkt bereitgestellt. Als Ergebnis sind diese Anwendungen oft leistungsempfindlich. Um neue Funktionen und Verbesserungen zu entwickeln, können Softwareupdates häufig sein. Da Frontend-Anwendungen in der Regel Backend-Anwendungen zum Speichern und Verwalten von Daten nutzen – und möglicherweise Geschäftslogik und Nutzereingaben –, sind sie oft zustandslos oder verwalten nur begrenzte Datenmengen.

Erstellen Sie Ihre Front-End-Anwendungen mit verschiedenen Frameworks und Technologien, damit sie zugänglich und brauchbar sind. Einige Schlüsselfaktoren für eine erfolgreiche Frontend-Anwendung sind Anwendungsleistung, Reaktionsgeschwindigkeit und Browserkompatibilität.

Die Komponenten der Back-End-Anwendung sind gewöhnlich auf das Speichern und Verwalten von Daten ausgelegt. Bei einigen Architekturen ist die Geschäftslogik in die Back-End-Komponente eingebunden. Neue Releases von Backend-Anwendungen müssen meist weniger oft vorgenommen werden als für Frontend-Anwendungen. Backend-Anwendungen haben folgende Herausforderungen zu bewältigen:

  • Eine große Anzahl von Anfragen verarbeiten
  • Große Datenmengen verarbeiten
  • Daten sichern
  • Aktuelle und aktualisierte Daten in allen Systemreplikaten beibehalten

Die dreistufige Anwendungsarchitektur ist eine der beliebtesten Implementierungen zum Erstellen von geschäftlichen Webanwendungen, wie E-Commerce-Websites mit verschiedenen Anwendungskomponenten. Diese Architektur umfasst die folgenden Ebenen: Jede Ebene arbeitet unabhängig, ist jedoch eng miteinander verknüpft und funktionieren alle zusammen.

  • Web-Front-End und Präsentationsstufe
  • Anwendungsstufe
  • Datenzugriff oder Back-End-Stufe

Durch das Einfügen dieser Schichten in Container werden ihre technischen Anforderungen getrennt, wie z. B. Skalierungsanforderungen und hilft, diese in einem schrittweisen Ansatz zu migrieren. Außerdem können Sie sie auf plattformunabhängigen Cloud-Diensten bereitstellen, die über Umgebungen hinweg portierbar sind, automatisierte Verwaltungsfunktionen nutzen und mit Cloud-verwalteten Plattformen wie Cloud Run oder Google Kubernetes Engine (GKE) Enterprise Edition skalieren. Außerdem helfen Von Google Cloud verwaltete Datenbanken wie Cloud SQL dabei, das Backend als Datenbankebene bereitzustellen.

Beim gestaffelten Hybridarchitekturmuster liegt der Schwerpunkt auf der Bereitstellung vorhandener Frontend-Anwendungskomponenten in der öffentlichen Cloud. Bei diesem Muster behalten Sie vorhandene Back-End-Anwendungskomponenten in ihrer privaten Rechenumgebung. Je nach Umfang und spezifischem Design der Anwendung können Sie Frontend-Anwendungskomponenten von Fall zu Fall migrieren. Weitere Informationen finden Sie unter Zu Google Cloud migrieren

Wenn Sie eine vorhandene Anwendung mit Backend- und Frontend-Komponenten haben, die in Ihrer lokalen Umgebung gehostet werden, berücksichtigen Sie die Einschränkungen Ihrer aktuellen Architektur. Wenn Ihre Anwendung beispielsweise skaliert wird und die Anforderungen an ihre Leistung und Zuverlässigkeit steigen, sollten Sie prüfen, ob Teile Ihrer Anwendung refaktoriert oder auf eine andere, optimalere Architektur umgestellt werden sollten. Mit dem gestaffelten hybriden Architekturmuster können Sie einige Anwendungslasten und Komponenten in die Cloud verlagern, bevor Sie komplett wechseln. Sie müssen auch die Kosten, Zeit und das Risiko berücksichtigen, die mit einer solchen Migration einhergehen.

Das folgende Diagramm zeigt ein typisches gestaffeltes Hybrid-Architekturmuster.

Datenfluss von einem lokalen Anwendungs-Frontend zu einem Anwendungs-Frontend in Google Cloud. Die Daten fließen dann zurück zur lokalen Umgebung.

Im obigen Diagramm werden Clientanfragen an das Frontend der Anwendung gesendet, das in Google Cloud gehostet wird. Das Frontend der Anwendung sendet dann Daten zurück in die lokale Umgebung, in der das Anwendungs-Back-End gehostet wird (idealerweise über ein API-Gateway).

Mit dem gestaffelten Hybridarchitekturmuster können Sie die Google Cloud-Infrastruktur und globale Dienste nutzen, wie in der Beispielarchitektur im folgenden Diagramm dargestellt. Das Frontend der Anwendung ist erreichbar über Google Cloud. Es kann auch die Flexibilität des Frontends erhöhen, indem es Autoscaling verwendet, um dynamisch und effizient auf die Skalierungsanforderung zu reagieren, ohne die Infrastruktur überzudimensionieren. Es gibt verschiedene Architekturen, mit denen Sie skalierbare Webanwendungen in Google Cloud erstellen und ausführen können. Jede Architektur hat Vor- und Nachteile je nach Anforderungen.

Weitere Informationen findest du im Video Drei Möglichkeiten zum Ausführen skalierbarer Webanwendungen in Google Cloud auf YouTube. Weitere Informationen über die verschiedenen Möglichkeiten zur Modernisierung Ihrer E-Commerce-Plattform auf Google Cloud, siehe So erstellen Sie eine digitale Handelsplattform in Google Cloud

Datenfluss von Nutzern zu einem lokalen Datenbankserver über Cloud Load Balancing und Compute Engine

Im obigen Diagramm wird das Frontend der Anwendung auf Google Cloud gehostet, um eine multiregionale und global optimierte User Experience bereitzustellen, die globales Load-Balancing, Autoscaling und DDoS-Schutz durch Google Cloud Armor nutzt.

Im Laufe der Zeit kann die Anzahl der Anwendungen, die Sie in der öffentlichen Cloud bereitstellen, so weit ansteigen, dass Sie eine Verlagerung von Backend-Anwendungskomponenten in die öffentliche Cloud in Betracht ziehen. Wenn Sie hohe Zugriffszahlen erwarten, empfiehlt es sich, mit Cloud-verwalteten Diensten den technischen Aufwand für die Verwaltung Ihrer eigenen Infrastruktur zu verringern. Nutzen Sie diese Option, sofern Sie nicht aufgrund von Einschränkungen oder Anforderungen Backend-Anwendungskomponenten vor Ort hosten müssen. Wenn Ihre Back-End-Daten beispielsweise gesetzlichen Vorschriften unterliegen, müssen Sie diese Daten wahrscheinlich lokal aufbewahren. Sofern anwendbar und konform, können Sie jedoch mit Sensitive Data Protection, wie z. B. Techniken zur De-Identifizierung, diese Daten bei Bedarf verschieben.

Beim gestaffelten Hybridarchitekturmuster können Sie in einigen Szenarien auch Google Distributed Cloud verwenden. Mit Distributed Cloud können Sie Google Kubernetes Engine-Cluster auf dedizierter Hardware ausführen, die von Google bereitgestellt und gewartet wird und die vom Google Cloud-Rechenzentrum getrennt ist. Um sicherzustellen, dass Distributed Cloud Ihre aktuellen und zukünftigen Anforderungen erfüllt, sollten Sie die Einschränkungen von Distributed Cloud im Vergleich zu einer herkömmlichen cloudbasierten GKE-Zone kennen.

Vorteile

Der primäre Fokus auf Frontend-Anwendungen bietet unter anderem folgende Vorteile:

  • Front-End-Komponenten sind von Back-End-Ressourcen und gelegentlich von anderen Frontend-Komponenten abhängig.
  • Backend-Komponenten hängen nicht von Frontend-Komponenten ab. Daher ist das Isolieren und Migrieren von Frontend-Anwendungen in der Regel weniger kompliziert als das Migrieren von Backend-Anwendungen.
  • Da Frontend-Anwendungen häufig zustandslos sind oder selbst keine Daten verwalten, ist deren Migration tendenziell einfacher als Back-Ends.

Die Bereitstellung vorhandener oder neu entwickelter Frontend-Anwendungen in der öffentlichen Cloud bietet einige Vorteile:

  • Viele Frontend-Anwendungen müssen oft geändert werden. Die Ausführung dieser Anwendungen in der öffentlichen Cloud vereinfacht das Einrichten eines Prozesses für die kontinuierliche Integration und Bereitstellung (Continuous Integration/Continuous Delivery, CI/CD). Mit CI/CD können Sie effiziente und automatisierte Aktualisierungen senden. Weitere Informationen finden Sie unter CI/CD in Google Cloud.
  • Leistungsempfindliche Frontends mit wechselndem Traffic können erheblich vom Load Balancing, multiregionalen Bereitstellungen, Cloud CDN Caching, Serverless und automatischen Skalierungsfunktionen profitieren, die eine cloudbasierte Bereitstellung (idealerweise mit zustandsloser Architektur) ermöglicht.
  • Bei der Einführung von Mikrodiensten mit Containern über eine cloudverwaltete Plattform wie GKE können Sie moderne Architekturen wie microfrontend verwenden, die Mikrodienste auf die Frontend-Komponenten ausweiten.

    Das Erweitern von Mikrodiensten wird häufig mit Front-Ends verwendet, bei denen mehrere Teams an derselben Anwendung zusammenarbeiten. Diese Art von Teamstruktur erfordert einen iterativen Ansatz und kontinuierliche Wartung. Das Verwenden von Mikro-Front-Ends bietet unter anderem folgende Vorteile:

    • Sie können unabhängige Mikrodienstmodule für Entwicklung, Tests und Bereitstellung sein.
    • Es bietet eine Trennung, in der die einzelnen Entwicklungsteams Technologien und Code auswählen können.
    • Es kann schnelle Entwicklungs- und Bereitstellungszyklen ermöglichen, ohne die übrigen Frontend-Komponenten zu beeinträchtigen, die möglicherweise von anderen Teams verwaltet werden.
  • Ob es um die Implementierung von Benutzeroberflächen oder APIs geht oder um die Erfassung von Daten aus dem Internet der Dinge (IoT), Frontend-Anwendungen können von den Möglichkeiten von Cloud-Diensten wie Firebase Pub/Sub Apigee Cloud CDN App Engine oder Cloud Run profitiern.

  • In der Cloud verwaltete API-Proxyshelfen bei:

    • Entkoppeln Sie die App-seitige API von Ihren Back-End-Diensten, z. B. Mikrodienste.
    • Apps vor Änderungen am Backend-Code schützen.
    • Sie unterstützen Ihre vorhandenen API-gestützten Frontend-Architekturen wie Backend für Frontend (BFF), Mikro-Frontend und andere.
    • Sie können Ihre APIs in Google Cloud oder in anderen Umgebungen verfügbar machen, indem Sie API-Proxys in Apigee implementieren.

Sie können das gestaffelte Hybridmuster auch umgekehrt anwenden. Dazu stellen Sie Backends in der Cloud, während Frontends in privaten Rechenumgebungen bleiben. Obwohl dieser Ansatz weniger gebräuchlich ist, eignet sich dieser Ansatz am besten für ein komplexes und monolithisches Frontend. In solchen Fällen kann es einfacher sein, die Back-End-Funktionalität iterativ zu extrahieren und diese neuen Back-Ends in der Cloud bereitzustellen.

Im dritten Teil dieser Serie werden mögliche Netzwerkmuster für diese Architektur erörtert. Apigee Hybrid kann als Plattform zum Erstellen und Verwalten von API-Proxys in einem hybriden Bereitstellungsmodell verwendet werden. Weitere Informationen finden Sie unter Lose gekoppelte Architektur: einschließlich mehrstufiger monolithischer Architektur und Mikrodienstarchitekturen.

Best Practices

Verwenden Sie die Informationen in diesem Abschnitt, wenn Sie Ihre mehrstufige Hybridarchitektur planen.

Best Practices zur Vereinfachung der Abläufe

Berücksichtigen Sie beim Anwenden des Architekturmusters gestaffelter Hybrid die folgenden Best Practices, um die allgemeine Bereitstellung und operative Komplexität zu reduzieren:

  • Basierend auf der Bewertung der Kommunikationsmodelle der identifizierten Anwendungen, wählen Sie die effizienteste und effektivste Kommunikationslösung für diese Anwendungen.

Da für die meisten Nutzerinteraktionen Systeme verwendet werden, die über mehrere Rechenumgebungen verbunden sind, ist eine schnelle Verbindung mit niedriger Latenz zwischen diesen Systemen sehr wichtig. Um die Erwartungen an Verfügbarkeit und Leistung zu erfüllen, sollten eine hohe Verfügbarkeit, geringe Latenzzeiten und ein angemessener Durchsatz gewährleistet sein. Aus Sicherheitsgründen muss die Kommunikation detailliert und kontrolliert werden. Idealerweise sollten Sie Anwendungskomponenten mit sicheren APIs bereitstellen. Weitere Informationen finden Sie unter Gated ausgehender Traffic.

  • Um die Kommunikationslatenz zwischen den Umgebungen zu minimieren, wählen Sie eine Google Cloud-Region aus, die geografisch in der Nähe der privaten Rechenumgebung liegt, in der Ihre Anwendungs-Backend-Komponenten gehostet werden. Weitere Informationen finden Sie unter Best Practices für die Auswahl der Region in Compute Engine.
  • Minimieren Sie großen Abhängigkeiten zwischen Systemen, die in verschiedenen Umgebungen ausgeführt werden, insbesondere wenn die Kommunikation synchron erfolgt. Diese Abhängigkeiten können die Leistung verlangsamen, die Gesamtverfügbarkeit verringern und zusätzliche Gebühren für die ausgehende Datenübertragung anfallen.
  • Beim gestaffelten hybriden Architekturmuster haben Sie möglicherweise ein größeres Volumen an eingehendem Traffic aus lokalen Umgebungen, der in die Google Cloud gelangt, als an ausgehendem Traffic, der die Google Cloud verlässt. Trotzdem sollten Sie die erwartete Volumen der ausgehenden Datenübertragung kennen, das die Google Cloud verlässt. Wenn Sie diese Architektur langfristig mit hohem ausgehenden Datenübertragungsvolumen verwenden möchten, sollten Sie Cloud Interconnect in Betracht ziehen. Mit Cloud Interconnect können Sie die Verbindungsleistung optimieren und die Kosten für die ausgehende Datenübertragung senken, die bestimmte Bedingungen erfüllen. Weitere Informationen finden Sie unter Cloud Interconnect-Preise.
  • Zum Schutz vertraulicher Daten empfehlen wir, alle öffentliche Kommunikation verschlüsseln. Wenn die Verschlüsselung auf der Verbindungsebene erforderlich ist, können Sie VPN-Tunnel, HA VPN over Cloud Interconnect und MACsec für Cloud Interconnect verwenden.
  • Um Inkonsistenzen bei Protokollen, APIs und Authentifizierungsmechanismen über verschiedene Back-Ends hinweg zu überwinden, empfehlen wir, sofern zutreffend, ein API-Gateway oder einen Proxy als einheitliche Fassade zu implementieren. Dieses Gateway oder dieser Proxy fungiert als zentraler Kontrollpunkt und führt die folgende Maßnahmen aus:

    • Implementiert zusätzliche Sicherheitsmaßnahmen.
    • Schützt Client-Apps und andere Dienste vor Änderungen am Back-End-Code.
    • Erleichtert Audit-Trails für die Kommunikation zwischen allen umgebungsübergreifenden Anwendungen und deren entkoppelten Komponenten.
    • Fungiert als Zwischenkommunikationsschicht zwischen Legacy- und modernisierten Diensten.
      • Mit Apigee und Apigee Hybrid können Sie Gateways für Unternehmen und Hybridgateways in lokalen Umgebungen, Edge-Umgebungen, anderen Clouds und Google Cloud-Umgebungen hosten und verwalten.
  • Verwenden Sie für die Einrichtung hybrider Konfigurationen Cloud Load Balancing mit Hybridkonnektivität Das bedeutet, dass Sie die Vorteile von Cloud Load Balancing auf Dienste ausweiten können, die in Ihrer lokalen Rechenumgebung gehostet werden. Dieser Ansatz ermöglicht eine stufenweise Migration von Arbeitslasten zu Google Cloud mit minimaler oder gar keiner Dienstunterbrechung und sorgt für einen reibungslosen Übergang für die verteilten Dienste. Weitere Informationen finden Sie unter Übersicht über Netzwerk-Endpunktgruppen mit Hybridkonnektivität

  • Manchmal ist die gemeinsame Verwendung eines API-Gateways oder eines Proxys und eines Application Load Balancer eine robustere Lösung für die Verwaltung, den Schutz und das Verteilen von API-Traffic in großem Maßstab. Mit Cloud Load Balancing mit API-Gateways können Sie Folgendes erreichen:

  • Verwenden Sie API-Verwaltung und Service Mesh zur Sicherung und Kontrolle von Dienstkommunikation und -sichtbarkeit mit Mikrodienstarchitektur.

    • Verwenden Sie Cloud Service Mesh, um die Dienst zu Dienst-Kommunikation zu ermöglichen, die die Qualität der Dienste in einem System aus verteilten Diensten aufrechterhält, in dem Sie die Authentifizierung, Autorisierung und Verschlüsselung zwischen den Diensten verwalten können.
    • Verwenden Sie eine API-Verwaltungsplattform wie Apigee, mit der Ihre Organisation und externe Entitäten diese Dienste nutzen können, indem Sie sie als APIs bereitstellen.
  • Richten Sie eine gemeinsame Identität zwischen Umgebungen ein, damit sich Systeme über Umgebungsgrenzen hinweg sicher authentifizieren können.

  • CI/CD- und Konfigurationsverwaltungssysteme in der öffentlichen Cloud bereitstellen Weitere Informationen finden Sie unter Gespiegeltes Netzwerkarchitekturmuster.

  • Um die betriebliche Effizienz zu steigern, verwenden Sie einheitliche Tools und CI/CD-Pipelines umgebungsübergreifend

Best Practices für individuelle Arbeitslast- und Anwendungsarchitekturen

  • Auch wenn der Fokus bei diesem Muster auf Frontend-Anwendungen liegt, sollten Sie die nötige Modernisierung von Ihren Backend-Anwendungen im Auge behalten. Wenn die Entwicklungsgeschwindigkeit von Back-End-Anwendungen wesentlich langsamer ist als bei Front-End-Anwendungen kann dieser Unterschied zusätzliche Komplexität verursachen.
  • Die Behandlung von APIs als Backend-Schnittstellen optimiert Integrationen, Frontend-Entwicklung, Dienstinteraktionen und verbirgt die Komplexität von Backend-Systemen. Um diese Herausforderungen zu meistern, vereinfacht Apigee die Entwicklung und Verwaltung von API-Gateways/Proxys für hybride und Multi-Cloud-Bereitstellungen.
  • Wählen Sie den Rendering-Ansatz für Ihre Frontend-Webanwendung basierend auf dem Inhalt (statisch oder Dynamik), die Leistung bei der Suchmaschinenoptimierung und die Erwartungen über die Seitenladegeschwindigkeiten.
  • Wenn Sie eine Architektur für inhaltsbasierte Webanwendungen auswählen, stehen verschiedene Optionen zur Verfügung, darunter monolithische, serverlose, ereignisbasierte und Mikrodienstarchitekturen. Um die am besten geeignete Architektur auszuwählen, prüfen Sie diese Optionen gründlich anhand Ihrer aktuellen und zukünftigen Anwendungsanforderungen. Informationen dazu, wie Sie eine Architekturentscheidung treffen, die Ihren geschäftlichen und technischen Zielen entspricht, finden Sie unter Vergleich verschiedener Architekturen für inhaltsorientierte Webanwendungs-Back-Ends und Überlegungen für Web-Backends.
  • Mit einer Mikrodienstarchitektur können Sie Containeranwendungen nutzen, mit Kubernetes als gemeinsame Laufzeitebene. Mit dem gestaffelten Hybridarchitekturmuster können Sie es in einem der folgenden Szenarien ausführen:

    • In beiden Umgebungen (Google Cloud und Ihren lokalen Umgebungen)

      • Wenn Sie Container und Kubernetes in verschiedenen Umgebungen verwenden, haben Sie die Flexibilität, Arbeitslasten zu modernisieren und zu unterschiedlichen Zeiten zu Google Cloud migrieren. Das ist hilfreich, wenn eine Arbeitslast stark von einer anderen abhängt und nicht einzeln migriert werden kann, oder um hybride Arbeitslast-Übertragbarkeit zu nutzen, um die besten in jeder Umgebung verfügbaren Ressourcen zu verwenden. In allen Fällen kann GKE Enterprise eine Schlüsseltechnologie sein. Weitere Informationen finden Sie unter Hybride GKE Enterprise-Umgebung
    • In einer Google Cloud-Umgebung für die migrierten und modernisierten Anwendungskomponenten.

      • Verwenden Sie diesen Ansatz, wenn Sie lokale Legacy-Back-Ends haben, die keine Containerisierungsunterstützung bieten oder viel Zeit und Ressourcen für die kurzfristige Modernisierung benötigen.

      Weitere Informationen zum Entwerfen und Refaktorieren einer monolithischen Anwendung zu einer Mikrodienstarchitektur zur Modernisierung der Architektur Ihrer Webanwendung finden Sie unter Einführung in Mikrodienste.

  • Sie können Datenspeichertechnologien je nach den Anforderungen für Ihre Webanwendungen erstellen. Cloud SQL für strukturierte Daten und Cloud Storage für Mediendateien ist ein gängiger Ansatz für die Erfüllung unterschiedlichen Datenspeicherbedarfs. Die Wahl hängt jedoch stark von Ihrem Anwendungsfall ab. Weitere Informationen zu Datenspeicheroptionen für inhaltsorientierte Anwendungs-Backends und effektive Modalitäten finden Sie unter Datenspeicheroptionen für inhaltsorientierte Webanwendungen Weitere Informationen finden Sie unter Erläuterung der Google Cloud-Datenbankoptionen.