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

אתם יכולים להיעזר בשיטות המומלצות שמופיעות כאן כשאתם מתזמנים את השירותים באמצעות 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

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

אפשר להשתמש ב-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, פונקציות או מחברים נכשלו, או אם השגיאות נוצרו על ידי קוד תהליך העבודה שלכם. מוסיפים טיפול בשגיאות וניסיונות חוזרים, כדי שכשל בשלב אחד לא יגרום לכשל של כל תהליך העבודה.

• אפשר