Zuletzt überprüft: Mai 2026
Eine übersichtliche Referenz der Architekturmuster, die in der PCD-Prüfung getestet werden. Von oben nach unten lesen oder zu einem Abschnitt springen.
Microservices erfordern sowohl synchrone Anfrage-/Antwort- als auch asynchrone ereignisgesteuerte Kommunikation.
Verwenden Sie gRPC oder HTTP für synchrone Aufrufe. Verwenden Sie Pub/Sub für asynchrone Ereignisverarbeitung und Fan-out.
Warum: Pub/Sub entkoppelt Dienste vollständig für Zuverlässigkeit und unabhängige Skalierung. Direkte Aufrufe ermöglichen synchrone Antworten mit geringer Latenz.
Ein zustandsloser Compute-Dienst (Cloud Run, Cloud Functions) muss temporäre Dateien verarbeiten.
Verwenden Sie Cloud Storage für alle temporären Datei-I/O.
Warum: Das lokale Dateisystem von Serverless-Plattformen ist temporär, im Speicher und nicht geteilt. Cloud Storage bietet dauerhaften, skalierbaren Speicher, auf den alle Instanzen zugreifen können.
Verwalten Sie umgebungsspezifische Konfigurationen und Secrets für GKE-Workloads gemäß den 12-Faktor-Prinzipien.
Verwenden Sie K8s ConfigMaps für nicht-sensible Konfigurationen. Verwenden Sie Secret Manager für sensible Werte, auf die sicher über Workload Identity zugegriffen wird.
Warum: Secret Manager ist eine sicherere, verwaltete und prüfbare Lösung als K8s Secrets. Workload Identity vermeidet die Verwaltung und Verteilung von Dienstkontoschlüsseln.
Die Anwendung hat extreme Verkehrsspitzen, aber lange Leerlaufzeiten, in denen die Kosten minimiert werden müssen.
Verwenden Sie Cloud Run mit `min-instances` auf 0 gesetzt.
Warum: Cloud Run kann auf Null skaliert werden, wodurch alle Compute-Kosten während Leerlaufzeiten entfallen. GKE und Compute Engine erfordern eine Mindestanzahl laufender Knoten/Instanzen.
Implementieren Sie Wiederholungsversuche, Circuit Breaker und mTLS konsistent über Microservices hinweg, ohne Änderungen am Anwendungscode vorzunehmen.
Stellen Sie ein Service Mesh (Anthos Service Mesh) auf GKE bereit.
Warum: Ein Service Mesh injiziert Resilienz, Sicherheit und Observability auf Plattformebene, hält den Anwendungscode sauber und gewährleistet konsistentes Verhalten.
Stellen Sie Backend-Dienste externen Partnern oder mobilen Apps mit Ratenbegrenzung, API-Schlüsseln und Nutzungsanalysen zur Verfügung.
Verwenden Sie API Gateway vor Backend-Diensten (z. B. Cloud Run, GKE).
Warum: API Gateway bietet eine vollständig verwaltete Lösung für API-Lifecycle-Anliegen (Sicherheit, Monitoring, Versionierung) und entlastet damit den Backend-Dienst.
Wählen Sie einen dauerhaften, skalierbaren und stark konsistenten Speicher für ein Nur-Anhängen-Protokoll von Ereignissen.
Verwenden Sie Cloud Spanner für den Ereignisspeicher.
Warum: Spanner bietet horizontale Skalierbarkeit mit starker globaler Konsistenz, was entscheidend ist, um die Integrität eines Ereignisprotokolls in großem Maßstab zu gewährleisten.
Eine API für einen langlaufenden Job muss sofort antworten, während die Verarbeitung im Hintergrund fortgesetzt wird.
Der API-Endpunkt reiht eine Aufgabe in Pub/Sub oder Cloud Tasks ein und gibt eine 202 Accepted mit einer Job-ID zurück. Ein separater Worker (Cloud Run, Cloud Function) verarbeitet die Aufgabe.
Warum: Dies entkoppelt die benutzerseitige Antwortzeit von der Backend-Verarbeitungszeit, verbessert die UX und die Systemzuverlässigkeit. Verwenden Sie Cloud Storage für Statusaktualisierungen.
Gewährleisten Sie Datenkonsistenz über mehrere Microservices hinweg ohne eine gemeinsame Datenbank.
Implementieren Sie das Saga-Muster mit einem Orchestrator (Cloud Workflows) oder einer Choreografie (Pub/Sub-Ereignisse) mit kompensierenden Transaktionen.
Warum: Vermeidet komplexe und zu Sperrungen neigende Zwei-Phasen-Commits und bevorzugt Eventual Consistency, die besser zu verteilten Systemen passt.
Die Anwendung ruft eine ratenbegrenzte Drittanbieter-API auf, deren Daten sich selten ändern.
Verwenden Sie Memorystore for Redis als verteilten Cache. Implementieren Sie das Cache-Aside-Muster mit TTL. Verwenden Sie eine verteilte Sperre (z. B. Redis SETNX), um Cache-Stampedes zu verhindern.
Warum: Ein verteilter Cache teilt Daten über alle Anwendungsinstanzen hinweg, reduziert drastisch die Aufrufe an die externe API, verbessert die Latenz und berücksichtigt Ratenbegrenzungen.
Ein Entwicklungsteam benötigt konsistente, vorkonfigurierte, sichere Entwicklungsumgebungen mit Zugriff auf private VPC-Ressourcen.
Verwenden Sie Cloud Workstations.
Warum: Cloud Workstations bietet verwaltete, containerbasierte Entwicklungsumgebungen mit integrierter Sicherheit und VPC-Zugriff, wodurch das Problem "es funktioniert auf meiner Maschine" gelöst wird.
Eine SaaS-Anwendung erfordert, dass Mieter vollständig isolierte Daten, Verschlüsselungsschlüssel und Datenresidenz haben.
Verwenden Sie ein Projekt-pro-Mandant-Modell. Verwalten Sie die Bereitstellung und Konfiguration zentral mit IaC (Terraform).
Warum: Bietet das höchste Maß an Isolation für IAM, Abrechnung, Quoten, Netzwerke und Datenstandorte, oft von Unternehmen oder regulierten Kunden gefordert.
Stellen Sie sicher, dass nur vertrauenswürdige, gescannte Container-Images aus einer offiziellen Pipeline in der Produktion bereitgestellt werden können.
Verwenden Sie Cloud Build, um SLSA-Provenienz zu generieren, Artifact Registry für Schwachstellenscans und Binary Authorization, um Bereitstellungsrichtlinien basierend auf Attestierungen durchzusetzen.
Warum: Erstellt eine überprüfbare, unumgehbare kryptografische Vertrauenskette vom Code bis zur Bereitstellung, die die Bereitstellung kompromittierter oder nicht gescannter Artefakte verhindert.
Stellen Sie eine neue Version eines Cloud Run-Dienstes bereit, testen Sie sie ohne Auswirkungen auf Benutzer und schalten Sie den Traffic sofort um.
Stellen Sie die neue Revision mit `--no-traffic` bereit. Testen Sie sie mit der eindeutigen Revisions-URL oder einem Revisions-Tag. Schalten Sie 100 % des Traffics auf die neue Revision um, sobald sie validiert wurde.
Warum: Die native Traffic-Verwaltung von Cloud Run ermöglicht sichere Bereitstellungen ohne Ausfallzeiten, indem die neue Version validiert wird, bevor sie Produktions-Traffic erhält.
Führen Sie schrittweise eine neue Version ein, analysieren Sie Metriken automatisch und führen Sie bei Fehlern ein Rollback durch.
Verwenden Sie Cloud Deploy mit einer Canary-Bereitstellungsstrategie. Integrieren Sie Cloud Monitoring für die automatisierte Metrikanalyse und Rollback-Trigger.
Warum: Cloud Deploy automatisiert den gesamten progressiven Bereitstellungs-Workflow, einschließlich Metrikanalyse und Sicherheitsprüfungen, wodurch manueller Aufwand und Risiko reduziert werden.
Verwalten Sie Kubernetes-Manifeste für Entwicklungs-, Staging- und Produktionsumgebungen ohne Code-Duplizierung.
Verwenden Sie Kustomize oder Helm. Definieren Sie eine Basiskonfiguration und erstellen Sie umgebungsspezifische Overlays oder Wertdateien, um Unterschiede einzufügen.
Warum: Folgt dem DRY-Prinzip, wodurch Konfigurationen einfacher zu verwalten sind und das Risiko einer Umgebungsabweichung reduziert wird.
Reduzieren Sie die Größe von Container-Images für schnellere Bereitstellungen und eine kleinere Angriffsfläche.
Verwenden Sie Multi-Stage Builds. Eine `build`-Phase verwendet ein vollständiges SDK/JDK-Image; die letzte Phase kopiert nur das kompilierte Artefakt in ein minimales `distroless` Basis-Image.
Warum: Das endgültige Image enthält nur die Anwendung und ihre Laufzeitabhängigkeiten und entfernt alle Build-Tools, Shells und Paketmanager.
Stellen Sie automatisch temporäre Umgebungen für jeden Pull-Request zur Validierung vor dem Mergen bereit.
Verwenden Sie Cloud Build-Trigger bei PR-Ereignissen, um auf Cloud Run mit einem Revisions-Tag (z. B. `pr-123`) bereitzustellen. Verwenden Sie einen weiteren Trigger beim Schließen des PR, um die getaggte Revision zu bereinigen.
Warum: Revisions-Tags bieten einzigartige, temporäre URLs für jeden PR ohne den Overhead der Erstellung neuer Dienste, was es kostengünstig und einfach zu automatisieren macht.
Verbessern Sie die CI/CD-Build-Geschwindigkeit und -Zuverlässigkeit durch Caching öffentlicher Softwareabhängigkeiten (z. B. von npm, Maven Central).
Verwenden Sie ein Remote-Repository des Artifact Registry, das als Pull-Through-Cache für das öffentliche Repository dient.
Warum: Verbessert die Build-Leistung, schützt Builds vor Ausfällen öffentlicher Registries und ermöglicht die Schwachstellensuche in gecachten Artefakten.
Speichern und sperren Sie den Terraform-Status sicher für gleichzeitige CI/CD-Pipeline-Ausführungen.
Verwenden Sie ein Cloud Storage-Backend für den Terraform-Status mit entsprechendem IAM für das Cloud Build-Dienstkonto.
Warum: Cloud Storage bietet ein dauerhaftes, versioniertes und sperrbares Backend, das eine Statusbeschädigung durch gleichzeitige Builds verhindert.
Ein Cloud Run- oder Cloud Function-Dienst muss auf eine Ressource (z. B. Cloud SQL, Memorystore) in einem privaten VPC-Netzwerk zugreifen.
Konfigurieren Sie einen Serverless VPC Access Connector.
Warum: Der Connector fungiert als Netzwerkbrücke, die den ausgehenden Traffic von der Serverless-Umgebung in die Ziel-VPC ermöglicht, ohne Ressourcen öffentlich zugänglich zu machen.
Eine zustandsbehaftete Anwendung auf GKE erfordert eine stabile Identität und persistenten Speicher, der Pod-/Knotenfehler überlebt.
Verwenden Sie ein StatefulSet mit einem Headless Service für die Identität. Verwenden Sie einen PersistentVolumeClaim (PVC) mit einer regionalen Persistent Disk für den Speicher.
Warum: Dies ist das kanonische Kubernetes-Muster für zustandsbehaftete Workloads, das Datenpersistenz, Hochverfügbarkeit und vorhersagbare Pod-Benennung/-Netzwerk gewährleistet.
Ein Pod auf GKE muss sicher auf GCP-APIs zugreifen, ohne statische Dienstkontoschlüssel verwalten zu müssen.
Konfigurieren und verwenden Sie Workload Identity.
Warum: Workload Identity bindet ein Kubernetes-Dienstkonto an ein Google-Dienstkonto, sodass Pods kurzlebige GCP-Anmeldeinformationen verwenden können, die vom Metadaten-Server abgerufen werden.
Führen Sie einen Batch-Job aus, dessen Abschluss Stunden dauert (z. B. Verarbeitung einer großen Datei, nächtliche Datenaggregation).
Verwenden Sie Cloud Run-Jobs, ausgelöst von Eventarc oder Cloud Scheduler.
Warum: Cloud Run-Jobs sind für langlaufende Aufgaben (bis zu 24 Stunden) konzipiert, skalieren auf Null und sind kostengünstiger und einfacher als ein dedizierter GKE-Cluster oder eine VM für Batch-Workloads.
Stellen Sie eine Multi-Container-Anwendung auf Cloud Run bereit, bei der ein Hauptcontainer einen Sidecar für Logging, Metriken oder als Proxy benötigt.
Stellen Sie den Cloud Run-Dienst mit mehreren angegebenen Container-Images bereit, eines als Hauptcontainer und andere als Sidecars.
Warum: Die native Multi-Container-Unterstützung von Cloud Run ermöglicht das Sidecar-Muster für Serverless-Workloads ohne die Komplexität von GKE.
Datenbankmigrationen müssen abgeschlossen sein, bevor eine neue Cloud Run-Revision Traffic empfängt.
Führen Sie Migrationen während des Container-Starts aus und verwenden Sie eine Cloud Run-Startup-Probe, die nur nach erfolgreichen Migrationen bestanden wird.
Warum: Die Startup-Probe verzögert das Traffic-Routing, bis der Container vollständig bereit ist, und stellt so sicher, dass das Datenbankschema korrekt ist, bevor Anfragen verarbeitet werden.
Eine GKE-Anwendung muss basierend auf einer benutzerdefinierten Metrik wie der Warteschlangentiefe von Pub/Sub skaliert werden, nicht nur CPU/Speicher.
Verwenden Sie den Horizontal Pod Autoscaler (HPA), der so konfiguriert ist, dass er benutzerdefinierte Metriken von Cloud Monitoring liest.
Warum: Dies ermöglicht es, die automatische Skalierung durch Geschäftslogik oder anwendungsspezifische Lastindikatoren zu steuern, was eine genauere Skalierung als generische Ressourcenmetriken bietet.
Ein nachrichtenbasierter Dienst muss jede Nachricht genau einmal verarbeiten, trotz Wiederholungsversuchen und potenziellen doppelten Zustellungen.
Kombinieren Sie Pub/Sub (mit At-Least-Once- oder Exactly-Once-Zustellung) mit einem idempotenten Consumer. Der Consumer verfolgt verarbeitete Nachrichten-IDs in einem persistenten Speicher (z. B. Firestore, Memorystore).
Warum: Pub/Sub garantiert die Zustellung, aber der Consumer ist für die Idempotenz verantwortlich, um Wiederholungsversuche auf Anwendungsebene zu handhaben und eine echte Exactly-Once-Verarbeitung zu erreichen.
Ereignisse, die sich auf dieselbe Entität beziehen (z. B. einen bestimmten Benutzer), müssen in der Reihenfolge verarbeitet werden, in der sie generiert wurden.
Veröffentlichen Sie Nachrichten in Pub/Sub mit einem `orderingKey`. Aktivieren Sie die Nachrichtenreihenfolge für das Abonnement.
Warum: Pub/Sub garantiert, dass Nachrichten mit demselben Ordering Key in der richtigen Reihenfolge zugestellt werden, während Nachrichten mit unterschiedlichen Keys parallel verarbeitet werden können, um die Skalierbarkeit zu erhöhen.
Stellen Sie sicher, dass eine Aufgabe (z. B. täglicher Benutzerbericht generieren) nur einmal ausgeführt wird, auch wenn mehrere Trigger-Ereignisse eintreffen.
Verwenden Sie Cloud Tasks. Erstellen Sie Aufgaben mit expliziten Namen (z. B. `report-userX-2024-10-26`). Cloud Tasks dedupliziert Anfragen zur Erstellung einer Aufgabe mit einem bereits vorhandenen Namen.
Warum: Dies verlagert die Deduplizierungslogik auf den Warteschlangendienst, vereinfacht den Anwendungscode und verhindert redundante Arbeit.
Eine Pub/Sub-Nachricht schlägt nach mehreren Wiederholungsversuchen ständig fehl und blockiert die Warteschlange.
Konfigurieren Sie ein Dead-Letter-Topic (DLQ) für das Pub/Sub-Abonnement und legen Sie eine maximale Anzahl von Zustellversuchen fest.
Warum: Pub/Sub verschiebt die "Problem"-Nachricht automatisch in die DLQ, wodurch andere Nachrichten verarbeitet werden können und die fehlgeschlagene Nachricht zur Analyse erhalten bleibt.
Ein Geschäftsprozess umfasst eine Abfolge von Dienstaufrufen mit bedingter Logik, Fehlerbehandlung und langen Wartezeiten.
Verwenden Sie Cloud Workflows, um die Orchestrierungslogik zu definieren und auszuführen.
Warum: Cloud Workflows ist ein Serverless-Orchestrator, der Zustände, Wiederholungsversuche und lange Wartezeiten verwaltet und so eine bessere Zuverlässigkeit und Sichtbarkeit bietet als manuell verkettete Funktionen.
Ein Cloud Function- oder Cloud Run-Dienst sollte nur durch bestimmte Cloud-Ereignisse ausgelöst werden (z. B. bestimmte Dateitypen in Cloud Storage).
Verwenden Sie einen Eventarc-Trigger mit CEL (Common Expression Language)-Filterung für Ereignisattribute.
Warum: Die Filterung erfolgt, bevor der Dienst aufgerufen wird, wodurch Kosten und Rechenzyklen gespart werden, da irrelevante Ereignisse nicht verarbeitet werden.
Begrenzen Sie ausgehende Aufrufe an eine Drittanbieter-API von einem horizontal skalierten Dienst wie Cloud Run.
Reihen Sie API-Aufrufe als Aufgaben in eine Cloud Tasks-Warteschlange mit konfigurierten `rateLimits` (z. B. maximale Versendungen pro Sekunde) ein.
Warum: Cloud Tasks bietet eine zentrale, serverlose Ratenbegrenzung, die über alle skalierten Instanzen hinweg funktioniert, ohne dass komplexe verteilte Zähler erforderlich sind.
Authentifizieren Sie Aufrufe zwischen zwei Cloud Run- (oder Cloud Functions-) Diensten sicher.
Erteilen Sie dem Dienstkonto des aufrufenden Dienstes die IAM-Rolle `roles/run.invoker` für den aufgerufenen Dienst. Der Aufrufer sendet ein von Google signiertes ID-Token mit seiner Anfrage.
Warum: Dies ist die native, sichere und schlüssellose Methode zur Dienst-zu-Dienst-Authentifizierung, die Googles Identitätsinfrastruktur nutzt.
Ein ereignisgesteuerter Dienst muss in nahezu Echtzeit auf zeilenweise Änderungen in einer Cloud SQL-Datenbank reagieren.
Verwenden Sie Datastream (CDC), um Datenbankänderungen an Pub/Sub zu streamen. Verwenden Sie Eventarc, um einen Cloud Run-Dienst aus dem Pub/Sub-Topic auszulösen.
Warum: Dies ist ein entkoppeltes, zuverlässiges Muster, das Datenbank-Polling vermeidet und keine Änderung der in die Datenbank schreibenden Anwendung erfordert.
Ein langlaufender Geschäftsprozess muss pausieren und auf ein externes Ereignis warten, z. B. wenn ein Mensch einen Genehmigungslink in einer E-Mail anklickt.
Verwenden Sie Cloud Workflows mit einem Callback-Endpunkt. Der Workflow pausiert (für bis zu ein Jahr), bis er eine HTTP-Anfrage an seiner eindeutigen Callback-URL empfängt.
Warum: Callbacks ermöglichen es Workflows, auf externe Ereignisse zu warten, ohne Rechenressourcen zu verbrauchen, was sie ideal für langlaufende Prozesse mit menschlicher Beteiligung macht.
Eine latenzempfindliche Serverless-Anwendung erfährt nach Leerlaufzeiten langsame initiale Antworten.
Konfigurieren Sie `min-instances` auf 1 oder mehr. Für unvermeidbare Kaltstarts verwenden Sie `startup-cpu-boost`. Optimieren Sie auch die Anwendung (kleineres Image, schnellere Initialisierung).
Warum: `min-instances` ist der effektivste Weg, Kaltstarts zu eliminieren, verursacht aber Kosten. `startup-cpu-boost` beschleunigt den Startvorgang selbst.
Eine Anfrage ist über mehrere Microservices hinweg langsam oder schlägt fehl, und der Engpass ist aus Logs oder individuellen Dienstmetriken nicht ersichtlich.
Verwenden Sie Cloud Trace mit Kontext-Propagierung. Instrumentieren Sie Anwendungen, um Trace-Header weiterzuleiten (z. B. W3C Trace Context).
Warum: Cloud Trace bietet eine Wasserfall-Visualisierung des gesamten Anforderungslebenszyklus über alle Dienste hinweg und identifiziert die Quelle von Latenz oder Fehlern.
Eine Anwendung läuft in der Produktion langsam, und es ist unklar, ob das Problem CPU-gebunden ist, ein Speicherleck oder I/O.
Verwenden Sie Cloud Profiler, um die CPU- und Heap-Nutzung in der Produktion kontinuierlich zu analysieren.
Warum: Cloud Profiler identifiziert Leistungsengpässe auf Code-Ebene (Hot Paths, Speicherlecks) mit sehr geringem Overhead, ohne Probleme in einer Testumgebung reproduzieren zu müssen.
Wechseln Sie von einfachen Schwellenwertwarnungen (z. B. "Latenz > 500ms") zu aussagekräftigeren Warnungen basierend auf Service Level Objectives (SLOs).
Definieren Sie SLIs und SLOs in Cloud Monitoring. Erstellen Sie Benachrichtigungsrichtlinien basierend auf der "Burn Rate" des Fehlerbudgets.
Warum: Burn Rate Alerts sind empfindlicher gegenüber signifikanten Änderungen und weniger "laut" als einfache Schwellenwertwarnungen. Sie signalisieren, wenn Sie auf dem Weg sind, Ihr SLO zu verfehlen.
Aggregieren Sie Anwendungs-Exceptions von mehreren Diensten, um deren Häufigkeit zu verfolgen, Stack-Traces anzuzeigen und über neue Fehlertypen benachrichtigt zu werden.
Verwenden Sie Cloud Error Reporting.
Warum: Error Reporting erfasst, gruppiert und analysiert Ausnahmen aus strukturierten Logs automatisch und bietet ein zentrales Dashboard zur Verwaltung von Anwendungsfehlern.
Überwachen, visualisieren und warnen Sie bei benutzerdefinierten Geschäftsmetriken (z. B. Bestellungen pro Minute, Benutzeranmeldungen).
Instrumentieren Sie den Anwendungscode mit dem OpenTelemetry SDK. Konfigurieren Sie den Exporter so, dass er Metriken an Cloud Monitoring sendet.
Warum: Dies ist der moderne, herstellerneutrale Standard für benutzerdefinierte Instrumentierung. Er ermöglicht die Verfolgung jeder Metrik und die Nutzung aller Funktionen von Cloud Monitoring dafür.