Best Practices für Workflows

Bei der Orchestrierung Ihrer Dienste mithilfe von Workflows können Sie sich an den hier aufgeführten Best Practices orientieren.

Dies ist keine vollständige Liste von Empfehlungen und vermittelt Ihnen nicht die Grundlagen der Verwendung von Workflows. In diesem Dokument wird davon ausgegangen, dass Sie bereits ein allgemeines Verständnis der gesamten Google Cloud-Landschaft und Workflows haben. Weitere Informationen finden Sie im Google Cloud-Architektur-Framework und in der Workflowübersicht.

Das optimale Kommunikationsmuster auswählen

Wenn Sie eine Mikrodienstarchitektur für die Bereitstellung mehrerer Dienste entwerfen, können Sie aus den folgenden Kommunikationsmustern auswählen:

  • Direkte Service-zu-Dienst-Kommunikation

  • Indirekte ereignisgesteuerte Kommunikation (auch als Choreografie bezeichnet)

  • Automatisierte Konfiguration, Koordination und Verwaltung (auch als Orchestrierung bezeichnet)

Berücksichtigen Sie die Vor- und Nachteile der vorherigen Optionen und wählen Sie ein optimales Muster für Ihren Anwendungsfall aus. Beispielsweise ist eine direkte Dienst-zu-Dienst-Kommunikation möglicherweise einfacher zu implementieren als andere Optionen, aber sie koppelt Ihre Dienste eng. Im Gegensatz dazu können Sie Ihre Dienste mit einer ereignisgesteuerten Architektur lose verknüpfen. Das Monitoring und die Fehlerbehebung können jedoch komplizierter sein. Schließlich ermöglicht Ihnen ein zentraler Orchestrator wie Workflows, obwohl diese weniger flexibel sind, die Kommunikation zwischen Diensten zu koordinieren, ohne die enge Verbindung zwischen der direkten Dienst-zu-Dienst-Kommunikation oder der Komplexität choreografierter Ereignisse zu bewältigen.

Sie können auch Kommunikationsmuster kombinieren. Bei einer ereignisgesteuerten Orchestrierung werden beispielsweise eng miteinander verbundene Dienste in einer Orchestrierung verwaltet, die durch ein Ereignis ausgelöst wird. In ähnlicher Weise können Sie ein System entwerfen, bei dem eine Orchestrierung zu einer Pub/Sub-Nachricht an ein anderes orchestriertes System führt.

Allgemeine Tipps

Wenn Sie sich für die Verwendung von Workflows als Dienstorchestrierung entschieden haben, beachten Sie die folgenden hilfreichen Tipps.

Hartcodierung von URLs vermeiden

Sie können Workflows unterstützen, die in mehrere Umgebungen übertragbar und durch den Verzicht auf hartcodierte URLs einfacher verwaltet werden können. Das erreichen Sie so:

  • Definieren Sie URLs als Laufzeitargumente.

    Dies kann hilfreich sein, wenn Ihr Workflow über eine Clientbibliothek oder die API aufgerufen wird. Dies funktioniert jedoch nicht, wenn der Workflow durch ein Ereignis aus Eventarc ausgelöst wird und das einzige Argument, das übergeben werden kann, die Ereignisnutzlast ist.

    Beispiel

    main:
  params: [args]
  steps:
    - init:
        assign:
          - url1: ${args.urls.url1}
          - url2: ${args.urls.url2}

    Wenn Sie den Workflow ausführen, können Sie die URLs angeben, z. B.:

    gcloud workflows run multi-env --data='{"urls":{"url1": "URL_ONE", "url2": "URL_TWO"}}'

  • Verwenden Sie Umgebungsvariablen und erstellen Sie einen Workflow, der abhängig von der Umgebung, in der er bereitgestellt wird, dynamisch konfiguriert wird. Oder erstellen Sie einen Workflow, der als Vorlage wiederverwendet und gemäß separat verwalteten Umgebungsvariablen konfiguriert werden kann.

  • Verwenden Sie ein Substitutionsverfahren, mit dem Sie eine einzelne Workflowdefinitionsdatei erstellen und Varianten mithilfe eines Tools bereitstellen können, das Platzhalter in Ihrem Workflow ersetzt. Sie können beispielsweise Cloud Build verwenden, um einen Workflow bereitzustellen, und in der Cloud Build-Konfigurationsdatei einen Schritt zum Ersetzen von Platzhalter-URLs im Workflow hinzufügen.

    Beispiel

    steps:
‐ id: 'replace-urls'
  name: 'gcr.io/cloud-builders/gcloud'
  entrypoint: bash
  args:
    - -c
    - |
      sed -i -e "s~REPLACE_url1~$_URL1~" workflow.yaml
      sed -i -e "s~REPLACE_url2~$_URL2~" workflow.yaml
‐ id: 'deploy-workflow'
  name: 'gcr.io/cloud-builders/gcloud'
  args: ['workflows', 'deploy', 'multi-env-$_ENV', '--source', 'workflow.yaml']

    Sie können die Variablenwerte dann bei der Build-Erstellung ersetzen. Beispiel:

    gcloud builds submit --config cloudbuild.yaml \
    --substitutions=_ENV=staging,_URL1="URL_ONE",_URL2="URL_TWO"

    Weitere Informationen finden Sie unter Build über Befehlszeile und API senden.

    Alternativ können Sie Terraform verwenden, um Ihre Infrastruktur bereitzustellen und mithilfe von Eingabevariablen eine Konfigurationsdatei zu definieren, die Workflows für jede Umgebung erstellt.

    Beispiel

    variable "project_id" {
  type = string
}

variable "url1" {
  type = string
}

variable "url2" {
  type = string
}

locals {
  env = ["staging", "prod"]
}

# Define and deploy staging and production workflows
resource "google_workflows_workflow" "multi-env-workflows" {
  for_each = toset(local.env)

  name            = "multi-env-${each.key}"
  project         = var.project_id
  region          = "us-central1"
  source_contents = templatefile("${path.module}/workflow.yaml", { url1 : "${var.url1}-${each.key}", url2 : "${var.url2}-${each.key}" })
}

    Wenn Variablen im Stammmodul der Konfiguration deklariert sind, können Sie ihnen auf verschiedene Arten Werte zuweisen. Beispiel:

    terraform apply -var="project_id=PROJECT_ID" -var="url1=URL_ONE" -var="url2=URL_TWO"

  • Mit dem Secret Manager-Connector können Sie URLs sicher in Secret Manager speichern und abrufen.

Verschachtelte Schritte verwenden

Jeder Workflow muss mindestens einen Schritt enthalten. Standardmäßig werden Schritte in Workflows so behandelt, als wären sie in einer sortierten Liste aufgeführt, und sie werden nacheinander ausgeführt, bis alle Schritte ausgeführt wurden. Logischerweise sollten einige Schritte gruppiert werden. Sie können einen steps-Block verwenden, um eine Reihe von Schritten zu verschachteln. Das ist praktisch, weil Sie so auf den richtigen atomaren Schritt verweisen können, um eine Reihe von Schritten zu verarbeiten.

Beispiel

main:
    params: [input]
    steps:
    - callWikipedia:
        steps:
        - checkSearchTermInInput:
            switch:
                - condition: ${"searchTerm" in input}
                  assign:
                    - searchTerm: ${input.searchTerm}
                  next: readWikipedia
        - getCurrentDate:
            call: http.get
            args:
                url: https://timeapi.io/api/Time/current/zone?timeZone=Europe/Amsterdam
            result: currentDate
        - setFromCallResult:
            assign:
                - searchTerm: ${currentDate.body.dayOfWeek}
        - readWikipedia:
            call: http.get
            args:
                url: https://en.wikipedia.org/w/api.php
                query:
                    action: opensearch
                    search: ${searchTerm}
            result: wikiResult
    - returnOutput:
            return: ${wikiResult.body[1]}

Ausdrücke umbrechen

Alle Ausdrücke müssen mit einem $ beginnen und in geschweiften Klammern gesetzt werden:

${EXPRESSION}

Um Probleme beim YAML-Parsing zu vermeiden, können Sie Ausdrücke in Anführungszeichen setzen. Ausdrücke, die Doppelpunkte enthalten, können beispielsweise zu unerwartetem Verhalten führen, wenn der Doppelpunkt als Definition einer Karte interpretiert wird. Sie können dieses Problem beheben, indem Sie den YAML-Ausdruck in einfache Anführungszeichen setzen:

'${"Name: " + myVar}'

Sie können auch Ausdrücke verwenden, die sich über mehrere Zeilen erstrecken. Beispielsweise müssen Sie möglicherweise eine SQL-Abfrage in Anführungszeichen setzen, wenn Sie den BigQuery-Connector für Workflows verwenden.

Beispiel

- runQuery:
    call: googleapis.bigquery.v2.jobs.query
    args:
        projectId: ${sys.get_env("GOOGLE_CLOUD_PROJECT_ID")}
        body:
            useLegacySql: false
            useQueryCache: false
            timeoutMs: 30000
            # Find top 100 titles with most views on Wikipedia
            query: ${
                "SELECT TITLE, SUM(views)
                FROM `bigquery-samples.wikipedia_pageviews." + table + "`
                WHERE LENGTH(TITLE) > 10
                GROUP BY TITLE
                ORDER BY SUM(VIEWS) DESC
                LIMIT 100"
                }
    result: queryResult

Die gesamte Workflowdefinition finden Sie unter Mehrere BigQuery-Jobs parallel ausführen.

Deklarative Aufrufe verwenden

Verwenden Sie Workflows, um Dienste aus dem Workflow selbst aufzurufen und die Ergebnisse zu verarbeiten. Außerdem können Sie damit einfache Aufgaben wie das Ausführen eines HTTP-Aufrufs ausführen. Workflows können Dienste aufrufen, Antworten parsen und Eingaben für andere verbundene Dienste erstellen. Durch den Aufruf eines Dienstes können Sie die Komplikationen von zusätzlichen Aufrufen, zusätzlichen Abhängigkeiten und Diensten, die Dienste aufrufen, vermeiden. Erwägen Sie, Dienste ohne Geschäftslogik durch deklarative API-Aufrufe zu ersetzen und Workflows zu verwenden, um Komplexität abzustrahieren.

Sie sollten jedoch Dienste für alle Aufgaben erstellen, die für Workflows zu komplex sind, z. B. für die Implementierung wiederverwendbarer Geschäftslogik, komplexe Berechnungen oder Transformationen, die nicht von Workflowausdrücken und deren Standardbibliothek unterstützt werden. Komplizierte Fälle lassen sich in der Regel einfacher im Code implementieren, als YAML oder JSON und die Workflow-Syntax zu verwenden.

Nur das speichern, was du brauchst

Halten Sie die Arbeitsspeichernutzung unter Kontrolle, damit Sie nicht auf Ressourcenlimits oder einen entsprechenden Fehler wie ResourceLimitError, MemoryLimitExceededError oder ResultSizeLimitExceededError stoßen.

Überlegen Sie genau, was Sie in Variablen speichern. Filtern und speichern Sie nur das, was Sie benötigen. Wenn ein Dienst eine zu große Nutzlast zurückgibt, verwenden Sie eine separate Funktion, um den Aufruf für Sie durchzuführen und nur das zurückzugeben, was erforderlich ist.

Sie können Arbeitsspeicher freigeben, indem Sie Variablen löschen. Beispielsweise können Sie Speicher freigeben, der für nachfolgende Schritte benötigt wird. Oder wenn Sie Ergebnisse haben, die für Sie irrelevant sind, und Sie diese Ergebnisse ganz weglassen können.

Sie können eine Variable löschen, indem Sie null zuweisen. In YAML können Sie einer Variablen auch einen leeren Wert oder ~ zuweisen. Dadurch wird Arbeitsspeicher identifiziert, der sicher freigegeben werden kann.

Beispiel

  - step:
      assign:
        - bigVar:

Untergeordnete und externe Workflows verwenden

Sie können untergeordnete Workflows verwenden, um eine Logik oder eine Reihe von Schritten zu definieren, die Sie mehrmals aufrufen möchten. Dadurch wird die Workflowdefinition vereinfacht. Untergeordnete Workflows ähneln einer Funktion oder Routine in einer Programmiersprache. Sie können Parameter akzeptieren und Werte zurückgeben, sodass Sie komplexere Workflows mit einer größeren Bandbreite von Anwendungen erstellen können.

Beachten Sie, dass untergeordnete Workflows lokal für Ihre Workflowdefinition gelten und nicht in anderen Workflows wiederverwendet werden können. Sie können jedoch Workflows aus anderen Workflows aufrufen. Die Workflows-Connectors können Ihnen dabei helfen. Weitere Informationen finden Sie in den Connector-Übersichten für die Workflow Executions API und die Workflows API.

Workflows-Connectors verwenden

Workflows bietet eine Reihe von connectors, mit denen der Zugriff auf andere Google Cloud-Produkte innerhalb eines Workflows erleichtert wird. Connectors vereinfachen das Aufrufen von Diensten, da sie die Formatierung von Anfragen für Sie übernehmen und Methoden und Argumente bereitstellen, sodass Sie die Details einer Google Cloud API nicht kennen müssen. Connectors haben auch ein integriertes Verhalten für die Verarbeitung von Wiederholungen und lang andauernden Vorgängen, damit Sie das Iterieren und Warten auf den Abschluss von Aufrufen vermeiden können. Connectors übernehmen dies für Sie.

Wenn Sie eine Google Cloud API aufrufen müssen, prüfen Sie zuerst, ob ein Workflow-Connector dafür vorhanden ist. Wenn Sie keinen Connector für ein Google Cloud-Produkt sehen, können Sie ihn auch anfordern.

Hier erfahren Sie, wie Sie einen Connector verwenden. Eine ausführliche Referenz zu verfügbaren Connectors finden Sie in der Connector-Referenz.

Workflowschritte parallel ausführen

Workflows können Schritte sequenziell ausführen, Sie können aber auch unabhängige Schritte parallel ausführen. In einigen Fällen kann dies die Ausführung Ihres Workflows erheblich beschleunigen. Weitere Informationen finden Sie unter Workflowschritte parallel ausführen.

Wiederholungsversuche und Saga-Muster anwenden

Gestalten Sie Workflows, die robust sind und sowohl vorübergehende als auch dauerhafte Dienstausfälle bewältigen können. Fehler für Workflows können beispielsweise durch fehlgeschlagene HTTP-Anfragen, Funktionen, Connectors oder durch Ihren eigenen Workflowcode generiert werden. Fügen Sie Fehlerbehandlung und Wiederholungsversuche hinzu, damit ein Fehler in einem Schritt nicht dazu führt, dass der gesamte Workflow fehlschlägt.

Einige Geschäftstransaktionen umfassen mehrere Dienste. Daher benötigen Sie einen Mechanismus zum Implementieren von Transaktionen, die Dienste umfassen. Das Saga-Designmuster ist eine Möglichkeit, die Datenkonsistenz in Mikrodiensten in verteilten Transaktionsszenarien zu verwalten. Eine Saga ist eine Abfolge von Transaktionen, die ein Ereignis für jede Transaktion veröffentlicht und die nächste Transaktion auslöst. Wenn eine Transaktion fehlschlägt, führt die Saga Kompensationstransaktionen aus, die den vorhergehenden Fehlern in der Sequenz entgegenwirken. Anleitung zu Wiederholungen und Saga-Muster in Workflows auf GitHub ausprobieren

Rückrufe zum Warten verwenden

Mit Callbacks kann bei Workflowausführungen gewartet werden, bis ein anderer Dienst eine Anfrage an den Callback-Endpunkt sendet. Mit dieser Anfrage wird die Ausführung des Workflows fortgesetzt.

Mit Callbacks können Sie Ihrem Workflow signalisieren, dass ein bestimmtes Ereignis eingetreten ist, und ohne Abfrage auf dieses Ereignis warten. Sie können beispielsweise einen Workflow erstellen, der Sie benachrichtigt, wenn ein Produkt wieder auf Lager ist oder versendet wurde oder mit menschlicher Interaktion wartet, z. B. beim Überprüfen eines Auftrags oder Validieren einer Übersetzung. Sie können auch mit Callbacks und Eventarc-Triggern auf Ereignisse warten.

Lang andauernde Jobs orchestrieren

Wenn Sie Arbeitslasten zur Batchverarbeitung mit langer Ausführungszeit ausführen müssen, können Sie Batch- oder Cloud Run-Jobs verwenden und die Dienste mit Workflows verwalten. Auf diese Weise können Sie Vorteile kombinieren und den gesamten Prozess effizient bereitstellen und orchestrieren.

Batch ist ein vollständig verwalteter Dienst, mit dem Sie Batch-Arbeitslasten auf Compute Engine-VM-Instanzen planen, in die Warteschlange stellen und ausführen können. Sie können den Workflows-Connector für Batch verwenden, um einen Batch-Job zu planen und auszuführen. Weitere Informationen finden Sie in der Anleitung.

Cloud Run-Jobs werden verwendet, um Code auszuführen, der die Arbeit (einen Job) ausführt und nach Abschluss der Arbeit beendet wird. Mit Workflows können Sie Cloud Run-Jobs als Teil eines Workflows ausführen, um eine komplexere Datenverarbeitung durchzuführen oder ein System vorhandener Jobs zu orchestrieren. Anleitung ansehen, in der gezeigt wird, wie Sie mit Workflows einen Cloud Run-Job ausführen

Lang andauernde Aufgaben containerisieren

Mit Workflows und Compute Engine können Sie die Ausführung eines Containers mit langer Laufzeit automatisieren. Sie können beispielsweise eine lang andauernde Aufgabe containerisieren, sodass sie überall ausgeführt werden kann, und den Container dann für die maximale Dauer der Workflowausführung (ein Jahr) auf einer Compute Engine-VM ausführen.

Mit Workflows können Sie das Erstellen der VM, das Ausführen des Containers auf der VM und das Löschen der VM automatisieren. Auf diese Weise können Sie einen Server verwenden und einen Container ausführen. Dadurch wird jedoch die komplexe Verwaltung beider Dinge vereinfacht. Außerdem kann es hilfreich sein, wenn Sie bei der Verwendung eines Dienstes wie Cloud Functions oder Cloud Run auf Zeitbeschränkungen stoßen. Die Anleitung Lang andauernde Container mit Workflows und Compute Engine auf GitHub testen

Befehlszeilentools über Workflows ausführen

Cloud Build ist ein Dienst, der Ihre Builds in Google Cloud als eine Reihe von Build-Schritten ausführt. Dabei wird jeder Build-Schritt in einem Docker-Container ausgeführt. Build-Schritte werden genauso wie Befehle in einem Skript ausgeführt.

Die Google Cloud CLI enthält die gcloud-, gsutil-, bq- und kubectl-Befehlszeilentools, es gibt jedoch keine direkte Möglichkeit, gcloud CLI-Befehle über Workflows auszuführen. Cloud Build stellt jedoch Container-Images zur Verfügung, die die gcloud CLI enthalten. Sie können gcloud CLI-Befehle in diesen Containern über einen Cloud Build-Schritt ausführen und diesen Schritt in Workflows mit dem Cloud Build-Connector erstellen.

Beispiel

Führen Sie gcloud in einem Workflow aus:

# This example shows how to execute gcloud commands from Workflows
# using Cloud Build and returns the output

main:
  steps:
  - execute_command:
      call: gcloud
      args:
          args: "workflows list"
      result: result
  - return_result:
      return: ${result}

gcloud:
  params: [args]
  steps:
  - create_build:
      call: googleapis.cloudbuild.v1.projects.builds.create
      args:
        projectId: ${sys.get_env("GOOGLE_CLOUD_PROJECT_ID")}
        parent: ${"projects/" + sys.get_env("GOOGLE_CLOUD_PROJECT_ID") + "/locations/global"}
        body:
          serviceAccount: ${sys.get_env("GOOGLE_CLOUD_SERVICE_ACCOUNT_NAME")}
          options:
            logging: CLOUD_LOGGING_ONLY
          steps:
          - name: gcr.io/google.com/cloudsdktool/cloud-sdk
            entrypoint: /bin/bash
            args: ${["-c", "gcloud " + args + " > $$BUILDER_OUTPUT/output"]}
      result: result_builds_create
  - return_build_result:
      return: ${text.split(text.decode(base64.decode(result_builds_create.metadata.build.results.buildStepOutputs[0])), "\n")}

Run kubectl in a workflow:

# This example shows how to execute kubectl commands from Workflows
# using Cloud Build and returns the output

main:
  steps:
  - execute_command:
      call: kubectl
      args:
          args: "--help"
      result: result
  - return_result:
      return: ${result}

kubectl:
  params: [args]
  steps:
  - create_build:
      call: googleapis.cloudbuild.v1.projects.builds.create
      args:
        projectId: ${sys.get_env("GOOGLE_CLOUD_PROJECT_ID")}
        parent: ${"projects/" + sys.get_env("GOOGLE_CLOUD_PROJECT_ID") + "/locations/global"}
        body:
          serviceAccount: ${sys.get_env("GOOGLE_CLOUD_SERVICE_ACCOUNT_NAME")}
          options:
            logging: CLOUD_LOGGING_ONLY
          steps:
          - name: gcr.io/cloud-builders/kubectl
            entrypoint: /bin/bash
            args: ${["-c", "kubectl " + args + " > $$BUILDER_OUTPUT/output"]}
      result: result_builds_create
  - return_build_result:
      return: ${text.split(text.decode(base64.decode(result_builds_create.metadata.build.results.buildStepOutputs[0])), "\n")}

Workflow mit Terraform erstellen

Terraform ist ein Infrastruktur-als-Code-Tool, mit dem Sie Ihre Cloud-Infrastruktur mithilfe von Code vorhersagbar erstellen, ändern und verbessern können.

Sie können einen Workflow mit der Terraform-Ressource google_workflows_workflow definieren und bereitstellen. Weitere Informationen finden Sie unter Workflow mit Terraform erstellen.

Für die Verwaltung großer Workflows können Sie Ihren Workflow in einer separaten YAML-Datei erstellen und diese Datei mithilfe der templatefile-Funktion in Terraform importieren. Diese Funktion liest eine Datei unter einem bestimmten Pfad und rendert ihren Inhalt als Vorlage.

Beispiel

  # Define a workflow
  resource "google_workflows_workflow" "workflows_example" {
    name            = "sample-workflow"
    region          = var.region
    description     = "A sample workflow"
    service_account = google_service_account.workflows_service_account.id
    # Import main workflow YAML file
    source_contents = templatefile("${path.module}/workflow.yaml",{})
  }

Wenn Sie einen Hauptworkflow haben, der mehrere untergeordnete Workflows aufruft, können Sie den Hauptworkflow und die untergeordneten Workflows in separaten Dateien definieren und die Funktion templatefile zum Importieren verwenden.

Beispiel

  # Define a workflow
  resource "google_workflows_workflow" "workflows_example" {
    name            = "sample-workflow"
    region          = var.region
    description     = "A sample workflow"
    service_account = google_service_account.workflows_service_account.id
    # Import main workflow and subworkflow YAML files
    source_contents = join("", [
      templatefile(
        "${path.module}/workflow.yaml",{}
      ),

      templatefile(
        "${path.module}/subworkflow.yaml",{}
      )])
  }

Wenn Sie sich beim Debuggen eines Workflows auf Zeilennummern beziehen, werden alle YAML-Dateien, die über die Terraform-Konfigurationsdatei importiert wurden, zusammengeführt und als ein Workflow bereitgestellt.

Workflow aus einem Git-Repository bereitstellen

Cloud Build verwendet Build-Trigger, um die CI/CD-Automatisierung zu aktivieren. Sie können Trigger so konfigurieren, dass eingehende Ereignisse überwacht werden, z. B. wenn ein neuer Commit per Push an ein Repository übertragen wird oder wenn eine Pull-Anfrage initiiert wird. Beim Eintreten neuer Ereignisse wird dann automatisch ein Build ausgeführt.

Sie können einen Cloud Build-Trigger verwenden, um automatisch einen Build zu starten und einen Workflow aus einem Git-Repository bereitzustellen. Sie können den Trigger so konfigurieren, dass der Workflow bei jeder Änderung im Quell-Repository oder nur dann bereitgestellt wird, wenn die Änderung bestimmte Kriterien erfüllt.

Dieser Ansatz kann Ihnen bei der Verwaltung des Bereitstellungslebenszyklus helfen. Sie können beispielsweise Änderungen an einem Workflow in einer Staging-Umgebung bereitstellen, Tests in dieser Umgebung ausführen und diese Änderungen dann schrittweise in der Produktionsumgebung starten. Weitere Informationen finden Sie unter Workflow aus einem Git-Repository mit Cloud Build bereitstellen.

Nutzung optimieren

Die Kosten für die Ausführung eines Workflows sind minimal. Bei einer hohen Nutzung sollten Sie jedoch die folgenden Richtlinien anwenden, um die Nutzung zu optimieren und die Kosten zu senken:

  • Anstatt benutzerdefinierte Domains zu verwenden, sollten Sie darauf achten, dass alle Aufrufe von Google Cloud-Diensten *.appspot.com, *.cloud.goog, *.cloudfunctions.net oder *.run.app verwenden. Dadurch werden Ihnen interne und keine externen Schritte in Rechnung gestellt.

  • Wenden Sie eine benutzerdefinierte Wiederholungsrichtlinie an, mit der die Latenz- und Zuverlässigkeitsanforderungen gegen die Kosten ausgeglichen werden. Häufigere Wiederholungen verringern die Latenz und erhöhen die Zuverlässigkeit, können aber auch die Kosten erhöhen.

  • Wenn Sie Connectors verwenden, die auf Vorgänge mit langer Ausführungszeit warten, können Sie eine benutzerdefinierte Abfragerichtlinie festlegen, um die Latenz für Kosten zu optimieren. Wenn Sie beispielsweise erwarten, dass ein Vorgang mehr als eine Stunde dauert, könnten Sie eine Richtlinie verwenden, die bei einem sofortigen Fehler zuerst nach einer Minute und anschließend alle 15 Minuten eine Abfrage durchführt.

  • Kombinieren Sie Zuweisungen in einem Schritt.

  • Vermeiden Sie die übermäßige Verwendung von sys.log Schritten. Verwenden Sie stattdessen Anruf-Logging.

Zusammenfassung der Best Practices

In der folgenden Tabelle sind die in diesem Dokument empfohlenen allgemeinen Tipps und Best Practices zusammengefasst.

Allgemeine Tipps
Best Practices

Nächste Schritte