Best Practices für Workflows

Sie können die hier aufgeführten Best Practices als Referenz verwenden, wenn Sie Ihre Dienste mithilfe von Workflows orchestrieren.

Diese Liste ist nicht vollständig und enthält keine grundlegenden Informationen zur Verwendung von Workflows. In diesem Dokument wird davon ausgegangen, dass Sie bereits ein allgemeines Verständnis der Google Cloud Branche und der Workflows haben. Weitere Informationen finden Sie im Google Cloud Architecture Framework und in der Workflow-Übersicht.

Optimales Kommunikationsmuster auswählen

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

  • Direkte Dienst-zu-Dienst-Kommunikation

  • Indirekte ereignisgesteuerte Kommunikation (auch als Choreographie bezeichnet)

  • Automatische Konfiguration, Koordination und Verwaltung (auch Orchestrierung genannt)

Berücksichtigen Sie die Vor- und Nachteile der einzelnen Optionen und wählen Sie ein optimales Muster für Ihren Anwendungsfall aus. Die direkte Kommunikation zwischen Diensten ist beispielsweise einfacher zu implementieren als andere Optionen, führt aber zu einer engen Kopplung Ihrer Dienste. Im Gegensatz dazu können Sie mit einer ereignisgesteuerten Architektur Ihre Dienste lose koppeln. Das Monitoring und die Fehlerbehebung können jedoch komplizierter sein. Schließlich können Sie mit einem zentralen Orchestrator wie Workflows 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 miteinander verbundene 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 orchestriertes System führt.

Allgemeine Tipps

Wenn Sie sich entschieden haben, Workflows als Dienstorchestrator zu verwenden, sollten Sie die folgenden hilfreichen Tipps beachten.

URLs nicht hartcodieren

Sie können Workflows unterstützen, die in mehreren Umgebungen verwendet werden können und einfacher zu verwalten sind, indem Sie hartcodierte URLs vermeiden. Dies ist auf folgende Arten möglich:

  • 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. Alternativ können Sie einen Workflow erstellen, der als Vorlage wiederverwendet und gemäß separat verwalteten Umgebungsvariablen konfiguriert werden kann.

  • Mit einer Substitutionstechnik können Sie eine einzelne Workflow-Definitiondatei erstellen, aber Varianten mit einem Tool bereitstellen, 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']

    Sie können dann Variablenwerte beim Build 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 Terraform verwenden, um Ihre Infrastruktur bereitzustellen und eine Konfigurationsdatei zu definieren, mit der Workflows für jede Umgebung mithilfe von Eingabevariablen erstellt werden.

    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 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 werden Schritte in Workflows so behandelt, als wären sie in einer sortierten Liste, und nacheinander ausgeführt, bis alle Schritte ausgeführt wurden. Logischerweise sollten einige Schritte gruppiert werden. Mit einem steps-Block können Sie eine Reihe von Schritten 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 umbrechen

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

${EXPRESSION}

Um Probleme beim YAML-Parsen zu vermeiden, können Sie Ausdrücke in Anführungszeichen setzen. Beispielsweise können Ausdrücke mit Doppelpunkten zu unerwartetem Verhalten führen, 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 mehrere Zeilen umfassen. Beispielsweise müssen Sie 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 vollständige Workflowdefinition 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 HTTP-Aufrufe ausführen. Workflows können Dienste aufrufen, Antworten analysieren und Eingaben für andere verbundene Dienste erstellen. Wenn Sie einen Dienst aufrufen, können Sie die Komplikationen zusätzlicher Aufrufe, zusätzlicher Abhängigkeiten und Dienste vermeiden, die Dienste aufrufen. Erwägen Sie, Dienste ohne Geschäftslogik durch deklarative API-Aufrufe zu ersetzen und Workflows zu verwenden, 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 Workflow-Ausdrücken und der Standardbibliothek nicht unterstützt werden. Komplexe Fälle lassen sich in der Regel einfacher in Code implementieren, als YAML oder JSON und die Workflow-Syntax zu verwenden.

Speichern Sie nur das, was Sie benötigen.

Behalten Sie den Arbeitsspeicherverbrauch im Auge, damit Sie nicht auf Ressourcenlimits stoßen oder Fehler wie ResourceLimitError, MemoryLimitExceededError oder ResultSizeLimitExceededError erhalten.

Achten Sie darauf, was Sie in Variablen speichern. Filtern Sie nur nach den Daten, die Sie benötigen, und speichern Sie nur diese. 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 Speicherplatz freigeben, indem Sie Variablen löschen. So können Sie beispielsweise Arbeitsspeicher freigeben, der für nachfolgende Schritte benötigt wird. Möglicherweise haben Sie auch Anrufe mit Ergebnissen, die Sie nicht interessieren, und können diese Ergebnisse ganz weglassen.

Sie können eine Variable löschen, indem Sie ihr null zuweisen. In YAML können Sie einer Variablen auch einen leeren Wert oder ~ zuweisen. So wird Speicherplatz ermittelt, der sicher wiederverwendet werden kann.

Beispiel

  - step:
      assign:
        - bigVar:

Untergeordnete Workflows und externe Workflows verwenden

Mit untergeordneten Workflows können Sie eine Logik oder eine Reihe von Schritten definieren, die Sie mehrmals aufrufen möchten. So 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 breiteren Palette von Anwendungen erstellen können.

Untergeordnete Workflows sind lokal für Ihre Workflowdefinition 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 Übersichten zu den Workflow Execution API und der Workflows API.

Workflows-Connectors verwenden

Workflows bietet eine Reihe von Connectors, die den Zugriff auf andere Google Cloud Produkte innerhalb eines Workflows erleichtern. 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 einerGoogle Cloud API nicht kennen. Connectors haben auch ein integriertes Verhalten für die Verarbeitung von Wiederholungsversuchen und lang andauernden Vorgängen. Sie müssen also nicht iterieren und auf den Abschluss von Aufrufen warten. Das erledigen die Connectors für Sie.

Wenn Sie eine Google Cloud API aufrufen möchten, prüfen Sie zuerst, ob es einen Workflows-Connector dafür gibt. Wenn Sie keinen Anschluss für ein Google Cloud Produkt sehen, können Sie ihn anfordern.

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

Workflowschritte parallel ausführen

In Workflows können Schritte nacheinander ausgeführt werden, aber auch unabhängige Schritte parallel. In einigen Fällen kann dies die Ausführung des Workflows erheblich beschleunigen. Weitere Informationen finden Sie unter Workflowschritte 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 Workflowcode verursacht werden. Fügen Sie eine Fehlerbehandlung und Wiederholungen hinzu, damit ein Fehler bei einem Schritt nicht zum Absturz des gesamten Workflows führt.

Einige Geschäftstransaktionen umfassen mehrere Dienste. Daher benötigen Sie einen Mechanismus, um Transaktionen zu implementieren, die mehrere Dienste umfassen. Das Saga-Designmuster ist eine Möglichkeit, die Datenkonsistenz in verteilten Transaktionsszenarien über Mikrodienste hinweg zu verwalten. Eine Saga ist eine Abfolge von Transaktionen, bei der für jede Transaktion ein Ereignis veröffentlicht und die nächste Transaktion ausgelöst wird. Wenn eine Transaktion fehlschlägt, führt die Saga Ausgleichstransaktionen aus, die die vorherigen Fehler in der Sequenz rückgängig machen. Sehen Sie sich die Anleitung zu Wiederholungen und dem Saga-Muster in Workflows auf GitHub an.

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 aufgetreten 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 pausiert, um menschliche Interaktion zu ermöglichen, z. B. die Überprüfung eines Auftrags oder die Validierung einer Übersetzung. Sie können auch mithilfe von Rückrufen und Eventarc-Triggern auf Ereignisse warten.

Langlaufende Jobs orchestrieren

Wenn Sie langlaufende Batchverarbeitungen ausführen müssen, können Sie Batch oder Cloud Run-Jobs verwenden. Mit Workflows können Sie die Dienste 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 stellen und ausführen können. Sie können den Workflows-Connector für Batch verwenden, um einen Batchjob zu planen und auszuführen. Weitere Informationen finden Sie in der Anleitung.

Cloud Run-Jobs werden verwendet, um Code auszuführen, der eine Arbeit ausführt (einen Job) 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. Sehen Sie sich die Anleitung an, 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 langlaufenden Containers mithilfe von Workflows und der Compute Engine automatisieren. Sie können beispielsweise eine lang laufende Aufgabe containerisieren, damit sie überall ausgeführt werden kann, und den Container dann für die maximale Dauer einer Workflowausführung (ein Jahr) auf einer Compute Engine-VM ausführen.

Mithilfe von Workflows können Sie das Erstellen der VM, das Ausführen 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 auf Zeitbeschränkungen stoßen. Sehen Sie sich die Anleitung Langlaufende Container mit Workflows und Compute Engine auf GitHub an.

Befehlszeilentools aus Workflows ausführen

Cloud Build ist ein Dienst, mit dem Ihre Builds auf Google Cloud als eine Reihe von Build-Schritten ausgeführt werden, 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 mit der gcloud CLI an. Sie können gcloud-Befehle in diesen Containern über einen Cloud Build-Schritt ausführen. Diesen Schritt können Sie in Workflows mit dem Cloud Build-Connector erstellen.

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 IaC-Tool (Infrastruktur als Code), mit dem Sie die Cloud-Infrastruktur mithilfe von Code vorhersehbar 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.

Um große Workflows zu verwalten und zu pflegen, können Sie Ihren Workflow in einer separaten YAML-Datei erstellen und diese Datei mithilfe der Funktion templatefile in Terraform importieren. Dabei wird eine Datei unter einem bestimmten Pfad gelesen und ihr Inhalt als Vorlage gerendert.

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 Haupt-Workflow haben, der mehrere untergeordnete Workflows aufruft, können Sie den Haupt-Workflow 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 Debuggen eines Workflows auf Zeilennummern verweisen, werden alle über die Terraform-Konfigurationsdatei importierten YAML-Dateien zusammengeführt und als einzelner 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 einen Build automatisch starten und einen Workflow aus einem Git-Repository bereitstellen. Sie können den Trigger so konfigurieren, dass er Ihren Workflow bei allen Änderungen am Quell-Repository oder nur bei Änderungen, die bestimmte Kriterien erfüllen, bereitstellt.

Dieser Ansatz kann Ihnen bei der Verwaltung Ihres Bereitstellungszyklus helfen. Sie können beispielsweise Änderungen an einem Workflow in einer Staging-Umgebung bereitstellen, Tests für diese Umgebung ausführen und diese Änderungen dann nach und nach in der Produktionsumgebung einführen. 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 einem hohen Nutzungsvolumen sollten Sie jedoch die folgenden Richtlinien beachten, um die Nutzung zu optimieren und die Kosten zu senken:

  • Verwenden Sie anstelle von benutzerdefinierten Domains *.appspot.com, *.cloud.goog, *.cloudfunctions.net oder *.run.app für alle Aufrufe von Google Cloud-Diensten, damit Ihnen nur interne und keine externen Schritte in Rechnung gestellt werden.

  • Wenden Sie eine benutzerdefinierte Wiederholungsrichtlinie an, die Ihre Anforderungen an Latenz und Zuverlässigkeit mit den Kosten in Einklang bringt. 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 lang laufende Vorgänge warten, legen Sie eine benutzerdefinierte Abfragerichtlinie fest, die die Latenz für die Kosten optimiert. Wenn Sie beispielsweise davon ausgehen, dass ein Vorgang länger als eine Stunde dauert, können Sie eine Richtlinie festlegen, die bei einem sofortigen Fehler zuerst nach einer Minute und dann alle 15 Minuten eine Abfrage durchführt.

  • Aufgaben in einem Schritt kombinieren

  • Vermeiden Sie eine übermäßige Verwendung von sys.log-Schritten. Sie können stattdessen Anrufprotokolle verwenden.

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