Best Practices für Workflows

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

Dies ist keine vollständige Liste von Empfehlungen und enthält keine Grundlagen zur Verwendung von Workflows. In diesem Dokument wird davon ausgegangen, dass Sie bereits ein allgemeines Verständnis der Gesamt Google Cloud landschaft und von Workflows haben. Weitere Informationen finden Sie im Google Cloud Well-Architected Framework und in der Übersicht zu Workflows.

Optimales Kommunikationsmuster auswählen

Beim Entwerfen einer Mikrodienste-Architektur für die Bereitstellung mehrerer Dienste können Sie aus den folgenden Kommunikationsmustern auswählen:

  • Direkte Dienst-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 einzelnen Optionen und wählen Sie ein optimales Muster für Ihren Anwendungsfall aus. Die direkte Dienst-zu-Dienst-Kommunikation ist beispielsweise einfacher zu implementieren als andere Optionen, aber sie koppelt Ihre Dienste eng. Im Gegensatz dazu können Sie mit einer ereignisgesteuerten Architektur Ihre Dienste lose koppeln. Das Monitoring und das Debugging sind jedoch möglicherweise komplizierter. Mit einem zentralen Orchestrator wie Workflows können Sie die Kommunikation zwischen Diensten koordinieren, ohne die enge Kopplung der direkten Dienst-zu-Dienst-Kommunikation oder die Komplexität choreografierter Ereignisse.

Sie können auch Kommunikationsmuster kombinieren. Bei der ereignisgesteuerten Orchestrierung werden beispielsweise eng verwandte Dienste in einer Orchestrierung verwaltet, die durch ein Ereignis ausgelöst wird. Ebenso, können Sie ein System entwerfen, bei dem eine Orchestrierung zu einer Pub/Sub-Nachricht an ein anderes orchestrierte System führt.

Allgemeine Tipps

Wenn Sie sich für Workflows als Dienstorchestrator entschieden haben, sollten Sie die folgenden hilfreichen Tipps beachten.

Hartcodierte URLs vermeiden

Sie können Workflows unterstützen, die über mehrere Umgebungen hinweg portierbar und einfacher zu verwalten sind, indem Sie hartcodierte URLs vermeiden. Dazu haben Sie folgende Möglichkeiten:

  • Definieren Sie URLs als Laufzeitargumente.

    Das kann hilfreich sein, wenn Ihr Workflow über eine Clientbibliothek oder die API aufgerufen wird. Das funktioniert jedoch nicht, wenn Ihr Workflow durch ein Ereignis von 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. Beispiel:

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

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

  • Verwenden Sie eine Substitutionstechnik, mit der Sie eine einzelne Workflow-Definitionsdatei erstellen, aber Varianten bereitstellen können. Dazu verwenden Sie ein Tool, 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 hinzufügen, um Platzhalter-URLs im Workflow zu ersetzen.

    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']

    Anschließend können Sie Variablenwerte zur Build-Zeit ersetzen. Beispiel:

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

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

    Alternativ können Sie mit Terraform Ihre Infrastruktur bereitstellen und eine Konfigurationsdatei definieren, die mit EingabevariablenWorkflows 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 Root-Modul Ihrer Konfiguration deklariert werden, können ihnen auf verschiedene Arten Werte zugewiesen werden. Beispiel:

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

  • Verwenden Sie den Secret Manager-Connector um URLs sicher in Secret Manager zu speichern und abzurufen.

Verschachtelte Schritte verwenden

Jeder Workflow muss mindestens einen Schritt haben. Standardmäßig behandelt Workflows Schritte so, als wären sie in einer sortierten Liste, und führt sie einzeln aus, bis alle Schritte abgeschlossen sind. Logischerweise sollten einige Schritte gruppiert werden. Sie können einen steps-Block verwenden, um eine Reihe von Schritten zu verschachteln. Das ist praktisch, da 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 umschließen

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

${EXPRESSION}

Um Probleme beim Parsen von YAML zu vermeiden, können Sie Ausdrücke in Anführungszeichen setzen. Ausdrücke mit Doppelpunkten können beispielsweise unerwartetes Verhalten verursachen, wenn der Doppelpunkt als Definition einer Zuordnung 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 Workflows BigQuery-Connector 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 vollständige Workflow-Definition finden Sie unter Mehrere BigQuery-Jobs parallel ausführen.

Deklarative Aufrufe verwenden

Mit Workflows können Sie Dienste aus dem Workflow selbst aufrufen und die Ergebnisse verarbeiten sowie einfache Aufgaben wie einen HTTP-Aufruf ausführen. Workflows können Dienste aufrufen, Antworten parsen und Eingaben für andere verbundene Dienste erstellen. Durch den Aufruf eines Dienstes vermeiden Sie die Komplikationen zusätzlicher Aufrufe, zusätzlicher Abhängigkeiten und Dienste, die Dienste aufrufen. Ersetzen Sie Dienste ohne Geschäftslogik durch deklarative API-Aufrufe und verwenden Sie Workflows, um die Komplexität zu abstrahieren.

Sie sollten jedoch Dienste erstellen, um Aufgaben auszuführen, die für Workflows zu komplex sind. Dazu gehören beispielsweise die Implementierung wiederverwendbarer Geschäftslogik, komplexer Berechnungen oder Transformationen, die von Workflows-Ausdrücken und der Standardbibliothek nicht unterstützt werden. Ein komplizierter Fall lässt sich in der Regel einfacher in Code implementieren, anstatt YAML oder JSON und die Workflows-Syntax zu verwenden.

Nur das speichern, was benötigt wird

Behalten Sie den Arbeitsspeicherverbrauch im Blick, damit Sie keine Ressourcenlimits erreichen oder einen Fehler erhalten, der darauf hinweist, z. B. ResourceLimitError, MemoryLimitExceededError, oder ResultSizeLimitExceededError.

Wählen Sie sorgfältig aus, was Sie in Variablenspeichern. Filtern Sie 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 auszuführen und nur das zurückzugeben, was erforderlich ist.

Sie können Arbeitsspeicher freigeben, indem Sie Variablen löschen. Möglicherweise müssen Sie beispielsweise Arbeitsspeicher freigeben, der für nachfolgende Schritte benötigt wird. Oder Sie haben Aufrufe mit Ergebnissen, die Sie nicht interessieren, und können diese Ergebnisse ganz weglassen.

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 Workflows 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 Workflow-Definition 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 einem breiteren Anwendungsbereich erstellen können.

Untergeordnete Workflows sind lokal für Ihre Workflow-Definition und können nicht in anderen Workflows wiederverwendet werden. 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 , die den Zugriff auf andere Produkte in einem Workflow erleichtern Google Cloud . Connectors vereinfachen den Aufruf von Diensten, da sie die Formatierung von Anfragen für Sie verarbeiten, und Methoden und Argumente bereitstellen. Sie müssen also die Details einer Google Cloud API nicht kennen. Connectors haben auch ein integriertes Verhalten für die Verarbeitung von Wiederholungsversuchen und lang andauernden Vorgängen, sodass Sie nicht iterieren und auf den Abschluss von Aufrufen warten müssen. Connectors übernehmen das für Sie.

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

Informationen zur Verwendung eines Connectors und eine detaillierte Referenz zu den verfügbaren Connectors finden Sie in der Referenz zu Connectors.

Workflow-Schritte parallel ausführen

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

Wiederholungsversuche und das Saga-Muster anwenden

Entwerfen 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 Workflow-Code ausgelöst 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, um Transaktionen zu implementieren, die mehrere Dienste umfassen. Das Saga-Entwurfsmuster ist eine Möglichkeit, die Datenkonsistenz über Mikrodienste hinweg in Szenarien mit verteilten Transaktionen zu verwalten. Eine Saga ist eine Folge von Transaktionen, die für jede Transaktion ein Ereignis veröffentlicht und die nächste Transaktion auslöst. Wenn eine Transaktion fehlschlägt, führt die Saga Ausgleichstransaktionen aus, die den vorherigen Fehlern in der Sequenz entgegenwirken. Probieren Sie die Anleitung Wiederholungsversuche und Saga-Muster in Workflows auf GitHub aus.

Mit Callbacks warten

Callbacks ermöglichen es Workflow Ausführungen, zu warten, bis ein anderer Dienst eine Anfrage an den Callback-Endpunkt sendet. Diese Anfrage setzt die Ausführung des Workflows fort.

Mit Callbacks können Sie Ihrem Workflow signalisieren, dass ein bestimmtes Ereignis auf getreten ist, und auf dieses Ereignis ohne Abfrage warten. Sie können beispielsweise einen Workflow erstellen, um Sie zu benachrichtigen, wenn ein Produkt wieder auf Lager ist oder wenn ein Artikel versendet wurde. Oder Sie erstellen einen Workflow, der wartet, um menschliche Interaktion zu ermöglichen, z. B. die Überprüfung eines Auftrags oder die Validierung einer Übersetzung. Sie können auch mit Callbacks und Eventarc-Triggern auf Ereignisse warten.

Lang andauernde Jobs orchestrieren

Wenn Sie lang andauernde Batchverarbeitungs Arbeitslasten ausführen müssen, können Sie Batch oder Cloud Run-Jobs verwenden und die Dienste mit Workflows verwalten. So können Sie Vorteile kombinieren und den gesamten Prozess effizient bereitstellen und orchestrieren.

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

Cloud Run-Jobs werden verwendet, um Code auszuführen, der eine Aufgabe (einen Job) ausführt und bei Abschluss 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. Probieren Sie die Anleitung aus, in der gezeigt wird, wie Sie mit Workflows einen Cloud Run-Job ausführen.

Lang andauernde Aufgaben containerisieren

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

Mit Workflows können Sie die Erstellung der VM, die Ausführung des Containers auf der VM und das Löschen der VM automatisieren. So können Sie einen Server verwenden und einen Container ausführen, aber die Komplexität der Verwaltung beider wird abstrahiert. Das kann hilfreich sein, wenn Sie bei der Verwendung eines Dienstes wie Cloud Run-Funktionen oder Cloud Run Zeitlimits erreichen. Probieren Sie die Anleitung Lang andauernde Container mit Workflows und Compute Engine auf GitHub aus.

Befehlszeilentools aus Workflows ausführen

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

Die Google Cloud CLI enthält die Befehlszeilentools gcloud, bq und kubectl. Es gibt jedoch keine direkte Möglichkeit, gcloud CLI Befehle aus Workflows auszuführen. Cloud Build bietet jedoch Container-Images, die die gcloud CLI enthalten. Sie können gcloud CLI-Befehle in diesen Containern über einen Cloud Build Schritt ausführen. Diesen Schritt können Sie in Workflows mit dem Cloud Build-Connectorerstellen.

Beispiel

gcloud in einem Workflow ausführen:

# 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 die Cloud-Infrastruktur mithilfe von Code vorhersehbar erstellen, ändern und verbessern können.

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

Um große Workflows zu verwalten und zu pflegen, können Sie Ihren Workflow in einer separaten YAML-Datei erstellen und diese Datei mit der templatefile Funktion in Terraform importieren. Diese Funktion liest eine Datei an 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 ein Hauptworkflow mehrere untergeordnete Workflows aufruft, können Sie den Hauptworkflow und die untergeordneten Workflows in separaten Dateien definieren und sie mit der Funktion templatefile importieren.

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 beim Debugging eines Workflows auf Zeilennummern verweisen, werden alle über die Terraform-Konfigurationsdatei importierten YAML-Dateien zusammengeführt und als ein einziger Workflow bereitgestellt.

Workflow aus einem Git-Repository bereitstellen

Cloud Build verwendet Build-Trigger, um die CI/CD-Automatisierung zu aktivieren. Sie können Trigger konfigurieren, um eingehende Ereignisse zu überwachen, z. B. wenn ein neuer Commit an ein Repository übertragen oder eine Pull-Anfrage initiiert wird, und dann automatisch einen Build ausführen, wenn neue Ereignisse eingehen.

Mit einem Cloud Build-Trigger können Sie automatisch einen Build starten und einen Workflow aus einem Git-Repository bereitstellen. Sie können den Trigger so konfigurieren, dass er Ihren Workflow bei jeder Änderung am Quell-Repository bereitstellt oder den Workflow nur bereitstellt, wenn die Änderung bestimmte Kriterien erfüllt.

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

Nutzung optimieren

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

  • Verwenden Sie keine benutzerdefinierten Domains, sondern nur Google Cloud services use *.appspot.com, *.cloud.goog, *.cloudfunctions.net, oder *.run.app damit Ihnen interne und nicht externe Schritte in Rechnung gestellt werden.

  • Wenden Sie eine benutzerdefinierte Richtlinie für Wiederholungsversuche an, die Ihre Anforderungen an Latenz und Zuverlässigkeit mit den Kosten in Einklang bringt. Häufigere Wiederholungsversuche senken die Latenz und erhöhen die Zuverlässigkeit, können aber auch die Kosten erhöhen.

  • Wenn Sie Connectors verwenden, die auf lang andauernde Vorgänge warten, legen Sie eine benutzerdefinierte Abfragerichtlinie fest, die die Latenz für die Kosten optimiert. Wenn ein Vorgang voraussichtlich länger als eine Stunde dauert, sollten Sie beispielsweise eine Richtlinie verwenden, die bei einem sofortigen Fehler zuerst nach einer Minute und dann alle 15 Minuten abfragt.

  • Kombinieren Sie Zuweisungen in einem Schritt.

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

  • Machen Sie sich klar, welche Vorgänge als Schritt gelten. Vorgänge, die nicht als eigene Schritte gelten, werden gezählt, wenn sie in einem entsprechenden Schritt verwendet werden. Beispiel: Das Folgende zählt als ein Schritt:

    - type_check:
    return: if(get_type((int("6"))) == integer, 1, 2)

    Wichtige Vorgänge, die auf das Limit für die maximale Anzahl von Schritten angerechnet werden und nicht, sind in der folgenden Tabelle kategorisiert:

    Kategorie Vorgang
    Zählt als Schritt
    • Datenvorgänge: Zuweisen und Zurückgeben von Werten
    • Ablaufsteuerung: Sprünge (next), Switches, Starten einer for Schleife und jede Iteration einer for Schleife
    • Aufrufe: Aufrufen von sys.get_env oder einer anderen Standardbibliothek Funktion, eines anderen Workflows oder eines Connectors
    • Nebenläufigkeit: Threads und parallele Ausführung erstellen
    • Fehlerbehandlung: Jeder raise, try, retry- und except-Block zählt als separater Schritt, auch wenn andere Vorgänge Teil desselben größeren Schritts sind.

      Ein Schritt, der einen try Block mit einem Aufrufvorgang enthält, zählt beispielsweise als drei Schritte: einer für den primären Schritt, einer für den Versuch und einer für den Aufruf. Durch Hinzufügen eines retry Blocks werden drei weitere Schritte hinzugefügt (einer für den Wiederholungsversuch, einer für den Versuch und einer für den Aufruf), sodass insgesamt sechs Schritte entstehen.
    Zählt nicht als Schritt

Zusammenfassung der Best Practices

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

Allgemeine Tipps
Best Practices

Nächste Schritte