Wenn Sie eine Webanwendung entwerfen, die auf einer Mikrodienstarchitektur basiert, entscheiden Sie, wie Sie die Features Ihrer Anwendung in Mikrodienste aufteilen und wie diese Mikrodienste als Teil der Anwendung aufgerufen werden. Für Dienste mit langer Ausführungszeit können Sie asynchrone Dienstaufrufe verwenden. In dieser Referenzarchitektur wird erläutert, wie Sie eine Containeranwendung bereitstellen, die Prozesse mit langer Ausführungszeit asynchron aufruft.
Dieses Referenzarchitekturdokument richtet sich an Entwickler und Architekten, die Mikrodienste mit modernen Technologien wie Google Kubernetes Engine (GKE) und Pub/Sub asynchron implementieren möchten. In diesem Dokument wird davon ausgegangen, dass Sie mit Mikrodiensten im Allgemeinen sowie mit Pub/Sub und GKE in Google Cloud vertraut sind.
Architektur
Das folgende Diagramm zeigt ein Beispielszenario, in dem eine Anwendung Miniaturansichten generiert. Das Generieren von Miniaturansichten kann eine ressourcenintensive Aufgabe sein und daher einige Zeit in Anspruch nehmen.
Abbildung 1. Ursprüngliche Architektur für die Bildverarbeitung, die auf der Verwendung von VMs basiert.
Im obigen Diagramm empfängt die Anwendung Bilddateien von Clients und generiert dann Miniaturansichten. In dieser Architektur wird die Anwendung mithilfe von VM-Instanzen in Compute Engine und mithilfe von Backend-Dateispeicher in Cloud Storage implementiert. Die Anwendung speichert Metadaten mit Cloud Storage. Cloud Load Balancing verteilt Anfragen auf mehrere VMs.
Damit sich der operative Aufwand für die Verwaltung von VMs verringert, migrieren Sie dieses System zu einer neuen Architektur, die keine VMs verwendet.
Das folgende Diagramm zeigt, wie dieser Ablauf durch verwaltete Dienste implementiert wird, die Benachrichtigungen und Mikrodienste verwenden, um asynchrone Aufrufe zwischen Komponenten des Systems zu implementieren.
Abbildung 2. Neue Architektur für die Bildverarbeitung, die auf Containern und asynchronem Messaging basiert.
In der neuen Architektur sendet der Client ein Bild an die Anwendung und die Anwendung lädt es in Cloud Storage hoch. Anschließend wird über Pub/Sub-Benachrichtigungen eine Nachricht in die Pub/Sub-Nachrichtenwarteschlange gestellt. Die Nachricht ruft einen Mikrodienst auf, der in GKE ausgeführt wird. Der Mikrodienst ruft das Bild aus Cloud Storage ab, generiert eine Miniaturansicht und lädt die Miniaturansicht in Cloud Storage hoch.
Überlegungen zum Design
Die folgenden Richtlinien können Ihnen bei der Entwicklung einer Architektur helfen, die den Anforderungen Ihrer Organisation hinsichtlich operativer Effizienz und Leistung entspricht.
Operative Effizienz
Die neue Architektur bietet folgende Vorteile:
Unabhängige Skalierbarkeit: In der ursprünglichen Architektur sind für die in Compute Engine ausgeführte Anwendung zwei Kernaufgaben vorhanden. Eine Aufgabe besteht darin, Dateien zu empfangen, und die andere Aufgabe, eine Miniaturansicht aus dem Originalbild zu generieren. Das Empfangen hochgeladener Dateien beansprucht Netzwerkbandbreite, während das Generieren von Miniaturansichten CPU-intensiv ist. Die Compute Engine-Instanzen könnten also nicht genug CPU-Ressourcen zum Generieren von Bildern haben, obwohl noch ausreichend Netzwerkressourcen zum Empfangen von Dateien vorhanden sind. In der neuen Architektur sind diese Aufgaben auf Cloud Storage und GKE verteilt, wodurch sie unabhängig voneinander skalierbar sind.
Einfaches Hinzufügen neuer Funktionen: Wenn Sie in der ursprünglichen Architektur Funktionen hinzufügen möchten, müssen Sie diese auf denselben Compute Engine-Instanzen bereitstellen. In der neuen Architektur können Sie eine Anwendung entwickeln und unabhängig hinzufügen. Sie können beispielsweise eine Anwendung zum Senden von E-Mails hinzufügen, damit Sie benachrichtigt werden, wenn eine neue Miniaturansicht generiert wird. Pub/Sub kann asynchrone Verbindungen zu der Anwendung zum Generieren von Miniaturansichten und zum Senden von E-Mails herstellen, ohne den ursprünglichen Code zu ändern, der in GKE ausgeführt wird.
Geringere Kopplung: In der ursprünglichen Architektur stellt die zeitliche Kopplung häufig ein Problem dar. Wenn ein E-Mail-Relais-Server nicht verfügbar ist und die Anwendung versucht, eine Benachrichtigung zu senden, schlägt die Benachrichtigung fehl. Da diese Prozesse eng miteinander gekoppelt sind, erhält ein Client unter Umständen keine erfolgreiche Antwort von der Anwendung. In der neuen Architektur ist das anders: Da das Generieren einer Miniaturansicht und das Senden einer Benachrichtigung lose gekoppelt sind, erhält der Client eine erfolgreiche Antwort.
Diese neue Architektur hat folgende Nachteile:
Zusätzlicher Aufwand für die Modernisierung der Anwendung: Die Containerisierung einer Anwendung ist zeit- und arbeitsaufwendig. Die neue Architektur verwendet mehr Dienste und muss in Bezug auf die Beobachtbarkeit anders angegangen werden. Dazu sind Änderungen am Anwendungsmonitoring, am Bereitstellungsprozess und an der Ressourcenverwaltung erforderlich.
Anforderung zum Umgang mit Duplikaten auf Anwendungsseite: Pub/Sub garantiert die mindestens einmalige Nachrichtenzustellung, was bedeutet, dass Nachrichtenduplikate gesendet werden können. Ihre Anwendung muss mit dieser Möglichkeit umgehen können.
Leistung
Die neue Architektur bietet eine effiziente Ressourcennutzung: In der ursprünglichen Architektur werden beim Skalieren von Compute Engine-Instanzen mehr Ressourcen für die Ausführung von Betriebssystemen verwendet. Mit GKE können Sie Serverressourcen durch Ausführung mehrerer Container auf wenigen Servern effizient nutzen (Bin-Packing). Container lassen sich schnell skalieren, sodass die neue Architektur kurze Lastspitzen bewältigen und danach die Ressourcen schnell wieder herunterskalieren kann, wenn die Aufgaben abgeschlossen sind.
Bereitstellung
Informationen zum Bereitstellen einer Beispielanwendung, die diese Architektur implementiert, finden Sie unter Mikrodienste bereitstellen, die Pub/Sub und GKE verwenden.
Nächste Schritte
- Mehr zu DevOps und zur Architekturfunktion, die mit dieser Referenzarchitektur in Verbindung steht
- Über den DevOps Quick Check erfahren, wo Sie im Vergleich zum Rest der Branche stehen
- Weitere Referenzarchitekturen, Diagramme und Best Practices finden Sie im Cloud-Architekturcenter.