שיטות מומלצות לשימוש בתהליכי עבודה

אתם יכולים להיעזר בשיטות המומלצות שמופיעות כאן כשאתם מתזמנים את השירותים באמצעות Workflows.

זוהי רשימה חלקית של המלצות, והיא לא כוללת הסבר על השימוש ב-Workflows. ההנחה במסמך הזה היא שיש לכם כבר הבנה כללית של התמונה הכוללת של Google Cloud ושל Workflows. מידע נוסף זמין במאמרים בנושא Google Cloud Well-Architected Framework וסקירה כללית על Workflows.

בחירה של דפוס תקשורת אופטימלי

כשמעצבים ארכיטקטורת מיקרו-שירותים לפריסת שירותים מרובים, אפשר לבחור מבין דפוסי התקשורת הבאים:

  • תקשורת ישירה בין שירותים

  • תקשורת עקיפה מבוססת-אירועים (נקראת גם כוריאוגרפיה)

  • הגדרה, תיאום וניהול אוטומטיים (שנקראים גם תזמור)

חשוב לשקול את היתרונות והחסרונות של כל אחת מהאפשרויות שצוינו למעלה ולבחור את הדפוס האופטימלי לתרחיש השימוש שלכם. לדוגמה, תקשורת ישירה בין שירותים עשויה להיות פשוטה יותר להטמעה מאפשרויות אחרות, אבל היא יוצרת תלות הדדית חזקה בין השירותים. לעומת זאת, ארכיטקטורה מבוססת-אירועים מאפשרת לכם ליצור צימוד רופף בין השירותים, אבל יכול להיות שיהיה יותר מסובך לבצע מעקב וניפוי באגים. לבסוף, כלי תזמור מרכזי כמו Workflows, שהוא פחות גמיש, מאפשר לכם לתאם את התקשורת בין השירותים בלי צימוד חזק של תקשורת ישירה בין שירותים, או המורכבות של אירועים מתוזמרים.

אפשר גם לשלב בין דפוסי תקשורת. לדוגמה, בתזמור מבוסס-אירועים, שירותים שקשורים זה לזה באופן הדוק מנוהלים בתזמור שמופעל על ידי אירוע. באופן דומה, יכול להיות שתתכננו מערכת שבה תזמור אחד יוביל להודעת Pub/Sub למערכת מתואמת אחרת.

טיפים כלליים

אחרי שתחליטו להשתמש ב-Workflows ככלי לניהול שירותים, כדאי לזכור את הטיפים הבאים.

הימנעות מקידוד קשיח של כתובות URL

כדי לתמוך בתהליכי עבודה שניתן להעביר בין סביבות שונות וקל יותר לתחזק אותם, מומלץ להימנע מקידוד קשיח של כתובות URL. אפשר לעשות זאת בדרכים הבאות:

  • הגדרת כתובות URL כארגומנטים של זמן ריצה.

    האפשרות הזו שימושית כשמפעילים את תהליך העבודה באמצעות ספריית לקוח או ה-API. (עם זאת, זה לא יעבוד אם תהליך העבודה מופעל על ידי אירוע מ-Eventarc והארגומנט היחיד שאפשר להעביר הוא מטען הייעודי (payload) של האירוע).

    דוגמה

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

    כשמריצים את תהליך העבודה, אפשר לציין את כתובות ה-URL. לדוגמה:

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

  • משתמשים במשתני סביבה ויוצרים תהליך עבודה שמוגדר באופן דינמי בהתאם לסביבה שבה הוא נפרס. לחלופין, אפשר ליצור תהליך עבודה שאפשר להשתמש בו שוב כתבנית ולהגדיר אותו בהתאם למשתני סביבה שמתעדכנים בנפרד.

  • משתמשים בטכניקת החלפה שמאפשרת ליצור קובץ הגדרה יחיד של תהליך עבודה, אבל פורסים וריאציות באמצעות כלי שמחליף ערכי placeholder בתהליך העבודה. לדוגמה, אפשר להשתמש ב-Cloud Build כדי לפרוס תהליך עבודה, ובקובץ ההגדרות של Cloud Build להוסיף שלב להחלפת כתובות URL של placeholder בתהליך העבודה.

    דוגמה

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

    לאחר מכן תוכלו להחליף את ערכי המשתנים בזמן הבנייה. לדוגמה:

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

    מידע נוסף זמין במאמר בנושא שליחת גרסת build באמצעות CLI ו-API.

    לחלופין, אפשר להשתמש ב-Terraform כדי להקצות את התשתית ולהגדיר קובץ הגדרות שיוצר תהליכי עבודה לכל סביבה באמצעות משתני קלט.

    דוגמה

    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}" })
}

    כשמצהירים על משתנים במודול הבסיסי של ההגדרה, אפשר להקצות להם ערכים בכמה דרכים. לדוגמה

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

  • שימוש במחבר Secret Manager כדי לאחסן כתובות URL בצורה מאובטחת ב-Secret Manager ולאחזר אותן.

שימוש בשלבים מקוננים

כל תהליך עבודה חייב לכלול לפחות שלב אחד. כברירת מחדל, כלי זרימות העבודה מתייחס לשלבים כאילו הם נמצאים ברשימה מסודרת, ומבצע אותם אחד אחרי השני עד שכל השלבים מסתיימים. מבחינה לוגית, צריך לקבץ כמה שלבים ביחד, ואפשר להשתמש בבלוק steps כדי להוסיף סדרה של שלבים. זה נוח כי אפשר להצביע על השלב האטומרי הנכון כדי לעבד קבוצה של שלבים.

דוגמה

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

גלישת ביטויים

כל הביטויים חייבים להתחיל ב-$ ולהיות מוקפים בסוגריים מסולסלים:

${EXPRESSION}

כדי למנוע בעיות בניתוח של YAML, אפשר להוסיף מירכאות לביטויים. לדוגמה, ביטויים שמכילים נקודתיים עלולים לגרום להתנהגות לא צפויה כשהנקודתיים מפורשות כהגדרת מיפוי. כדי לפתור את הבעיה הזו, צריך להוסיף מירכאות יחידות סביב ביטוי ה-YAML:

'${"Name: " + myVar}'

אפשר גם להשתמש בביטויים שמתפרסים על כמה שורות. לדוגמה, יכול להיות שתצטרכו להוסיף מרכאות לשאילתת SQL כשמשתמשים במחבר BigQuery של Workflows.

דוגמה

- 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

הגדרת תהליך העבודה המלאה מופיעה במאמר הרצת כמה משימות BigQuery במקביל.

שימוש בהצהרות של שיחות

אפשר להשתמש ב-Workflows כדי לקרוא לשירותים מתוך תהליך העבודה עצמו ולטפל בתוצאות, וגם כדי לבצע משימות פשוטות כמו ביצוע קריאת HTTP. תהליכי עבודה יכולים להפעיל שירותים, לנתח תשובות וליצור קלט לשירותים מקושרים אחרים. הפעלת שירות מאפשרת לכם להימנע מהסיבוכים של הפעלות נוספות, יחסי תלות נוספים ושירותים שמפעילים שירותים. כדאי להחליף שירותים שאין בהם לוגיקה עסקית בקריאות API הצהרתיות, ולהשתמש ב-Workflows כדי להסתיר את המורכבות.

עם זאת, כדאי ליצור שירותים כדי לבצע פעולות מורכבות מדי בשביל Workflows. למשל, הטמעה של לוגיקה עסקית לשימוש חוזר, חישובים מורכבים או טרנספורמציות שלא נתמכות על ידי ביטויים של Workflows והספרייה הרגילה שלו. בדרך כלל קל יותר להטמיע תרחיש מורכב בקוד, במקום להשתמש ב-YAML או ב-JSON ובתחביר של Workflows.

שומרים רק את מה שצריך

חשוב לשלוט בצריכת הזיכרון כדי שלא תיתקלו במגבלות על משאבים או בשגיאה שמציינת זאת, כמו ResourceLimitError, MemoryLimitExceededError או ResultSizeLimitExceededError.

כדאי לבחור בקפידה מה מאחסנים במשתנים, לסנן ולאחסן רק את מה שצריך. אם שירות מחזיר מטען ייעודי (payload) גדול מדי, צריך להשתמש בפונקציה נפרדת כדי לבצע את הקריאה ולהחזיר רק את מה שנדרש.

כדי לפנות זיכרון, אפשר לנקות את המשתנים. לדוגמה, יכול להיות שתרצו לפנות זיכרון שנדרש לשלבים הבאים. לחלופין, יכול להיות שיהיו לכם שיחות עם תוצאות שלא מעניינות אתכם, ותוכלו להשמיט את התוצאות האלה לגמרי.

כדי לנקות משתנה, מקצים לו את הערך null. ב-YAML, אפשר גם להקצות למשתנה ערך ריק או ~. הפונקציה הזו מזהה זיכרון שאפשר לפנות בבטחה.

דוגמה

  - step:
      assign:
        - bigVar:

שימוש בתהליכי משנה ובתהליכי עבודה חיצוניים

אתם יכולים להשתמש בתהליכי עבודה משניים כדי להגדיר חלק מהלוגיקה או קבוצה של שלבים שאתם רוצים להפעיל כמה פעמים, וכך לפשט את הגדרת תהליך העבודה. תת-תהליכי עבודה דומים לפונקציה או לשגרה בשפת תכנות. הם יכולים לקבל פרמטרים ולהחזיר ערכים, וכך מאפשרים לכם ליצור תהליכי עבודה מורכבים יותר עם מגוון רחב יותר של יישומים.

חשוב לזכור שתהליכי עבודה משניים הם מקומיים להגדרת תהליך העבודה, ואי אפשר לעשות בהם שימוש חוזר בתהליכי עבודה אחרים. עם זאת, אפשר להתקשר לתהליכי עבודה מתהליכי עבודה אחרים. מחברי Workflows יכולים לעזור לכם בכך. מידע נוסף מופיע בסקירות הכלליות של המחברים עבור Workflow Executions API ו-Workflows API.

שימוש במחברים של Workflows

ב-Workflows יש מספר מחברים שמקלים על הגישה למוצרי Google Cloud Google אחרים בתהליך עבודה. מחברים מפשטים את הקריאה לשירותים כי הם מטפלים בפורמט של הבקשות בשבילכם, ומספקים שיטות וארגומנטים כך שלא תצטרכו לדעת את הפרטים שלGoogle Cloud API. בנוסף, למחברים יש התנהגות מובנית לטיפול בניסיונות חוזרים ובפעולות ארוכות טווח, כך שלא צריך לחזור על פעולות ולחכות לסיום השיחות. המחברים מטפלים בזה בשבילכם.

אם אתם צריכים להתקשר ל-API, כדאי קודם לבדוק אם קיים מחבר Workflows בשבילו. Google Cloud אם אתם לא רואים מחבר ל Google Cloud מוצר, אתם יכולים לבקש אותו.

איך משתמשים במחבר. במאמר הזה מפורטות הפניות למחברים הזמינים.

הרצת שלבים בתהליך עבודה במקביל

אפשר להריץ שלבים בתהליך העבודה באופן עוקב, אבל אפשר גם להריץ שלבים עצמאיים במקביל. במקרים מסוימים, זה יכול לזרז באופן משמעותי את הביצוע של תהליך העבודה. מידע נוסף זמין במאמר בנושא ביצוע שלבים בתהליך עבודה במקביל.

החלת ניסיונות חוזרים ודפוס סאגה

עיצוב תהליכי עבודה עמידים שיכולים להתמודד עם תקלות זמניות וקבועות בשירות. יכול להיות שיוצגו שגיאות בתהליכי עבודה, למשל אם בקשות HTTP, פונקציות או מחברים נכשלו, או אם השגיאות נוצרו על ידי קוד תהליך העבודה שלכם. מוסיפים טיפול בשגיאות וניסיונות חוזרים, כדי שכשל בשלב אחד לא יגרום לכשל של כל תהליך העבודה.

חלק מהעסקאות העסקיות מתפרסות על פני כמה שירותים, ולכן צריך מנגנון ליישום עסקאות שמתפרסות על פני שירותים. תבנית העיצוב של סאגה היא דרך לנהל את עקביות הנתונים במיקרו-שירותים בתרחישים של טרנזקציות מבוזרות. סאגה היא רצף של עסקאות שמתפרסם בהן אירוע לכל עסקה, והיא מפעילה את העסקה הבאה. אם עסקה נכשלת, סאגה מבצעת עסקאות מפצות שמבטלות את הכשלים הקודמים ברצף. כדאי לנסות את המדריך בנושא ניסיונות חוזרים ודפוס Saga ב-Workflows ב-GitHub.

שימוש בהחזרות שיחה כדי להמתין

החזרות (callbacks) מאפשרות להריץ תהליכי עבודה בהמתנה עד ששירות אחר ישלח בקשה אל נקודת הקצה של ההחזרה. הבקשה הזו מפעילה מחדש את תהליך העבודה.

באמצעות קריאות חוזרות (callback), אתם יכולים לציין בתהליך העבודה שאירוע מסוים התרחש, ולהמתין לאירוע הזה בלי לבדוק. לדוגמה, אתם יכולים ליצור תהליך עבודה ששולח לכם הודעה כשמוצר חוזר למלאי או כשפריט נשלח, או תהליך עבודה שממתין לאינטראקציה אנושית, כמו בדיקת הזמנה או אימות תרגום. אפשר גם לחכות לאירועים באמצעות קריאות חוזרות (callback) וטריגרים של Eventarc.

תזמור של משימות לטווח ארוך

אם אתם צריכים להריץ עומסי עבודה של עיבוד באצווה לזמן רב, אתם יכולים להשתמש ב-Batch או במשימות של Cloud Run, וב-Workflows כדי לנהל את השירותים. כך תוכלו לשלב בין היתרונות, להקצות משאבים ולתזמן את כל התהליך בצורה יעילה.

‫Batch הוא שירות שמנוהל במלואו שמאפשר לתזמן, להוסיף לתור ולהפעיל עומסי עבודה באצווה במכונות וירטואליות (VM) של Compute Engine. אתם יכולים להשתמש במחבר Workflows ל-Batch כדי לתזמן ולהריץ משימת Batch. פרטים נוספים זמינים במדריך.

משימות Cloud Run משמשות להרצת קוד שמבצע עבודה (משימה) ומפסיק לפעול כשהעבודה מסתיימת. בעזרת Workflows אפשר להריץ משימות של Cloud Run כחלק מתהליך עבודה כדי לבצע עיבוד נתונים מורכב יותר או לתזמן מערכת של משימות קיימות. אפשר לנסות את המדריך שמדגים איך להשתמש ב-Workflows כדי להריץ משימה ב-Cloud Run.

העברת משימות ממושכות לקונטיינר

אתם יכולים להשתמש ב-Workflows וב-Compute Engine כדי להפוך לאוטומטית את ההרצה של קונטיינר שפועל לאורך זמן. לדוגמה, אתם יכולים להכניס משימה שפועלת לאורך זמן לקונטיינר כדי שהיא תוכל לפעול בכל מקום, ואז להריץ את הקונטיינר במכונה וירטואלית ב-Compute Engine למשך הזמן המקסימלי של הרצת תהליך עבודה (שנה אחת).

באמצעות Workflows, אפשר להפוך לאוטומטיות את הפעולות הבאות: יצירת מכונה וירטואלית, הפעלת הקונטיינר במכונה הווירטואלית ומחיקת המכונה הווירטואלית. כך אפשר להשתמש בשרת ולהריץ קונטיינר, אבל המערכת מסתירה את המורכבות של ניהול שניהם. זה יכול להיות שימושי אם יש לכם מגבלות זמן כשאתם משתמשים בשירות כמו פונקציות Cloud Run או Cloud Run. מומלץ לנסות את המדריך בנושא קונטיינרים שפועלים לאורך זמן עם Workflows ו-Compute Engine ב-GitHub.

הרצת כלי שורת פקודה מ-Workflows

‫Cloud Build הוא שירות שמריץ את גרסאות ה-build שלכם ב- Google Cloud כסדרה של שלבי build, כאשר כל שלב מורץ בקונטיינר של Docker. הרצת שלבי build דומה להרצת פקודות בסקריפט.

‫Google Cloud CLI כולל את כלי שורת הפקודה gcloud, ‏ bq ו-kubectl, אבל אין דרך ישירה להריץ פקודות של ה-CLI של gcloud מ-Workflows. עם זאת, Cloud Build מספק תמונות קונטיינר שכוללות את ה-CLI של gcloud. אפשר להריץ פקודות gcloud CLI בקונטיינרים האלה משלב Cloud Build, ואפשר ליצור את השלב הזה ב-Workflows באמצעות המחבר של Cloud Build.

דוגמה

הפעלת gcloud בתהליך עבודה:

# 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")}

שימוש ב-Terraform ליצירת תהליך העבודה

‫Terraform הוא כלי מסוג תשתית כקוד (IaC), שמאפשר ליצור, לשנות ולשפר בצורה חזויה את תשתית הענן באמצעות קוד.

אפשר להגדיר ולפרוס תהליך עבודה באמצעות משאב Terraform‏ google_workflows_workflow. מידע נוסף זמין במאמר יצירת תהליך עבודה באמצעות Terraform.

כדי לעזור לכם לנהל ולתחזק תהליכי עבודה גדולים, אתם יכולים ליצור את תהליך העבודה בקובץ YAML נפרד ולייבא את הקובץ הזה ל-Terraform באמצעות הפונקציה templatefile, שקוראת קובץ בנתיב נתון ומציגה את התוכן שלו כתבנית.

דוגמה

  # 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",{})
  }

באופן דומה, אם יש לכם תהליך עבודה ראשי שקורא לכמה תהליכי משנה, אתם יכולים להגדיר את תהליך העבודה הראשי ואת תהליכי המשנה בקבצים נפרדים, ולהשתמש בפונקציה templatefile כדי לייבא אותם.

דוגמה

  # 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",{}
      )])
  }

שימו לב: אם אתם מתייחסים למספרי שורות כשאתם מנפים באגים בתהליך עבודה, כל קובצי ה-YAML שיובאו דרך קובץ ההגדרות של Terraform ימוזגו וייפרסו כתהליך עבודה יחיד.

פריסת תהליך עבודה ממאגר Git

‫Cloud Build משתמש בטריגרים של גרסאות build כדי להפעיל אוטומציה של CI/CD. אפשר להגדיר טריגרים שיאזינו לאירועים נכנסים, למשל כששולחים קומיט חדש למאגר או כשמתחילים בקשת משיכה, ואז יבצעו אוטומטית בנייה כשאירועים חדשים יגיעו.

אתם יכולים להשתמש בטריגר לפיתוח גרסת Build של Cloud Build כדי להתחיל באופן אוטומטי בבנייה ולפרוס תהליך עבודה ממאגר Git. אפשר להגדיר את הטריגר כך שיפרוס את זרימת העבודה בכל שינוי במאגר המקור, או לפרוס את זרימת העבודה רק כשהשינוי תואם לקריטריונים ספציפיים.

הגישה הזו יכולה לעזור לכם לנהל את מחזור החיים של הפריסה. לדוגמה, אפשר לפרוס שינויים בתהליך עבודה בסביבת ביניים, להריץ בדיקות בסביבה הזו ואז להשיק את השינויים האלה בהדרגה בסביבת הייצור. מידע נוסף זמין במאמר פריסת תהליך עבודה ממאגר Git באמצעות Cloud Build.

אופטימיזציה של השימוש

העלות של הפעלת תהליך עבודה היא מינימלית. עם זאת, אם אתם משתמשים ב-API בהיקף גדול, כדאי לפעול לפי ההנחיות הבאות כדי לייעל את השימוש ולהפחית את העלויות:

  • במקום להשתמש בדומיינים מותאמים אישית, צריך לוודא שכל הקריאות לשירותים של Google Cloudמשתמשות ב-*.appspot.com, ב-*.cloud.goog, ב-*.cloudfunctions.net או ב-*.run.app, כדי שייחובו לכם שלבים פנימיים ולא חיצוניים.

  • להחיל מדיניות ניסיון חוזר בהתאמה אישית שתאזן בין הצרכים שלכם בנוגע לזמן האחזור והמהימנות לבין העלויות. ניסיונות חוזרים בתדירות גבוהה יותר מקצרים את זמן האחזור ומשפרים את האמינות, אבל יכולים גם להגדיל את העלויות.

  • כשמשתמשים במחברים שממתינים לפעולות ממושכות, צריך להגדיר מדיניות מותאמת אישית של שליחת בקשות כדי לבצע אופטימיזציה של זמן האחזור לפי עלות. לדוגמה, אם אתם מצפים שפעולה מסוימת תימשך יותר משעה, כדאי להגדיר מדיניות שלפיה המערכת תבצע סקר ראשוני אחרי דקה אחת במקרה של כשל מיידי, ואז כל 15 דקות לאחר מכן.

  • משלבים מטלות לשלב אחד.

  • לא מומלץ להשתמש ביותר מדי שלבים sys.log. במקום זאת, כדאי להשתמש ברישום שיחות.

  • הסבר על הפעולות שנחשבות לשלב. פעולות שלא נספרות כשמשתמשים בהן בנפרד נספרות כשמשתמשים בהן בשלב רלוונטי. לדוגמה, הפעולה הבאה נחשבת לשלב אחד:

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

    בטבלה הבאה מפורטות פעולות מרכזיות שנספרות ופעולות מרכזיות שלא נספרות במסגרת המגבלה על מספר השלבים:

    קטגוריה פעולה
    נחשב כשלב
    • פעולות על נתונים: הקצאה, החזרה של ערכים
    • שליטה בתהליך: קפיצות (next), מעברים, התחלה של לולאה for וכל איטרציה של לולאה for
    • קריאות: הפעלה של sys.get_env או של פונקציה אחרת בספרייה רגילה, של תהליך עבודה אחר או של מחבר
    • מקביליות: יצירת שרשורים וביצוע מקביל
    • טיפול בשגיאות: כל אחד מהבלוקים raise, try, retry ו-except נחשב לשלב נפרד, גם אם פעולות אחרות הן חלק מאותו שלב גדול יותר.

      לדוגמה, שלב שכולל בלוק try עם פעולת קריאה נחשב לשלושה שלבים: אחד לשלב הראשי, אחד לניסיון ואחד לקריאה. הוספה של בלוק retry מוסיפה עוד שלושה שלבים (אחד לכל אחד מהניסיונות החוזרים, הניסיונות והקריאות), כך שיהיו בסך הכול שישה שלבים.
    לא נספר כשלב

סיכום השיטות המומלצות

בטבלה הבאה ריכזנו את הטיפים הכלליים והשיטות המומלצות שמופיעים במאמר הזה.

טיפים כלליים
שיטות מומלצות

המאמרים הבאים