סקירה כללית על Eventarc Standard

‫Eventarc מאפשר לכם ליצור ארכיטקטורות מבוססות-אירועים בלי שתצטרכו להטמיע, להתאים אישית או לתחזק את התשתית הבסיסית.

‫Eventarc מוצע בשתי מהדורות: Eventarc Advanced ו-Eventarc Standard. שתי המהדורות מציעות פתרון מבוסס-אירועים עם יכולת התאמה לעומס, ללא שרת (serverless) ומנוהל באופן מלא, שמאפשר לכם לנתב אירועים ממקורות ליעדים באופן אסינכרוני. מידע נוסף זמין במאמר בנושא בחירה בין Eventarc Advanced לבין Eventarc Standard.

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

אפשר לנהל את Eventarc דרך מסוף Google Cloud , דרך שורת הפקודה באמצעות ה-CLI של gcloud או באמצעות Eventarc API.

ב-Eventarc, אירועים מנותבים מספקי אירועים ליעדי אירועים.
ב-Eventarc Standard אפשר לנתב אירועים מספקי אירועים ליעדי אירועים (לחצו על התרשים כדי להגדיל).

1 אירועים מספקי Google נשלחים ישירות מהמקור (לדוגמה, Cloud Storage) או דרך רשומות ביומני הביקורת של Cloud, והם משתמשים ב-Pub/Sub כשכבת התעבורה. אירועים ממקורות Pub/Sub יכולים להשתמש בנושא Pub/Sub קיים, או ש-Eventarc ייצור נושא באופן אוטומטי וינהל אותו בשבילכם.

2 אירועים ליעדים של Google Kubernetes Engine‏ (GKE) – כולל שירותי Knative serving שפועלים באשכול GKE – משתמשים במעביר האירועים של Eventarc כדי לשלוף אירועים חדשים מ-Pub/Sub ולהעביר אותם ליעד. המרכיב הזה משמש כמתווך בין שכבת התעבורה של Pub/Sub לבין שירות היעד. הוא פועל בשירותים קיימים ותומך גם בשירותי איתות (כולל כאלה שלא נחשפים מחוץ לאשכול המנוהל באופן מלא), תוך פישוט ההגדרה והתחזוקה. שימו לב שמחזור החיים של מעביר האירועים מנוהל על ידי Eventarc, ואם תמחקו בטעות את מעביר האירועים, Eventarc ישחזר את הרכיב הזה.

‫3 אירועים להרצת תהליך עבודה עוברים טרנספורמציה ומועברים לתהליך העבודה כארגומנטים של זמן ריצה. תהליכי עבודה יכולים לשלב ולתזמר שירותי API מבוססי- Google Cloud ומבוססי-HTTP בסדר שאתם מגדירים.

4 כל הפונקציות מבוססות-האירועים ב-Cloud Run functions משתמשות בטריגרים של Eventarc כדי להעביר אירועים. אתם יכולים להגדיר טריגרים של Eventarc כשפורסים פונקציה של Cloud Run באמצעות הממשק של פונקציות Cloud Run.

תרחישי שימוש עיקריים

‫Eventarc תומך בתרחישי שימוש רבים עבור אפליקציות יעד. דוגמאות:

הגדרה ומעקב
  • הגדרת מערכת: התקנת כלי לניהול הגדרות במכונה וירטואלית חדשה כשהיא מופעלת.
  • תיקון אוטומטי: זיהוי אם שירות לא מגיב כמו שצריך והפעלה מחדש שלו באופן אוטומטי.
  • התראות: מעקב אחרי היתרה בכתובת של ארנק מטבעות וירטואליים ושליחת התראות.
Harmonize
  • רישומים בספרייה: הפעלת תג עובד כשעובד חדש מצטרף לחברה.
  • סנכרון נתונים: הפעלת תהליך עבודה של הנהלת חשבונות כשלקוח פוטנציאלי מומר במערכת CRM.
  • תיוג משאבים: תיוג וזיהוי של יוצר מכונה וירטואלית כשהיא נוצרת.
ניתוח
  • ניתוח סנטימנט: אפשר להשתמש ב-Cloud Natural Language API כדי לאמן ולפרוס מודל ML שמצרף ציון שביעות רצון לכרטיס תמיכה של לקוח כשהוא מסתיים.
  • ריטוש וניתוח תמונות: הסרת הרקע וסיווג אוטומטי של תמונה כשקמעונאי מוסיף אותה למאגר אובייקטים.

אירועים

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

אפשר לעיין בסוגי האירועים של Google שנתמכים על ידי Eventarc.

ספקי אירועים

האירועים מנותבים מספק האירועים (המקור) לצרכני האירועים שמתעניינים בהם. הניתוב מתבצע על סמך מידע שכלול באירוע, אבל אירוע לא מזהה יעד ניתוב ספציפי. ‫Eventarc תומך באירועים מיותר מ-130 ספקי Google. הספקים האלה שולחים אירועים (לדוגמה, עדכון של אובייקט בקטגוריה של Cloud Storage או הודעה שפורסמה בנושא Pub/Sub) ישירות מהמקור, או דרך רשומות ביומני הביקורת של Cloud.

יעדים של אירועים

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

Cloud Run

איך יוצרים שירות לקבלת אירועים שאפשר לפרוס ב-Cloud Run

כדי להבין איך הכי טוב לנתב אירועים לשירות Cloud Run, אפשר לעיין במאמר בנושא נתיבי אירועים.

פונקציות Cloud Run

כל הפונקציות מבוססות-האירועים ב-Cloud Run משתמשות בטריגרים של Eventarc כדי להעביר אירועים. טריגר Eventarc מאפשר להפעיל פונקציה על ידי כל סוג אירוע שנתמך על ידי Eventarc. כשפורסים פונקציה של Cloud Run באמצעות הממשק של Cloud Run Functions, אפשר להגדיר טריגרים של Eventarc.

GKE

‫Eventarc תומך ביצירת טריגרים שמכוונים לשירותי Google Kubernetes Engine‏ (GKE). זה כולל את נקודות הקצה הציבוריות של שירותים פרטיים וציבוריים שפועלים באשכול GKE.

  • כדי ש-Eventarc יוכל לטרגט ולנהל שירותים בכל אשכול נתון, צריך לתת לחשבון השירות של Eventarc את כל ההרשאות הנדרשות.

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

נקודות קצה (endpoint) פנימיות של HTTP ברשת VPC

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

Workflows

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

פורמט האירוע וספריות

‫Eventarc מעביר אירועים, בלי קשר לספק, ליעד המטרה בפורמט CloudEvents באמצעות בקשת HTTP במצב תוכן בינארי. ‫CloudEvents היא מפרט לתיאור מטא-נתונים של אירועים בצורה משותפת.

בהתאם לספק האירועים, אפשר לציין את הקידוד של נתוני מטען הייעודי (payload) של האירוע כ-application/json או כ-application/protobuf. ‫Protocol Buffers (או Protobuf) הוא מנגנון ניתן להרחבה, שאינו תלוי בשפה או בפלטפורמה, לסריאליזציה של נתונים מובְנים. שימו לב לנקודות הבאות:

  • האפשרות הזו של עיצוב לא נתמכת במקורות בהתאמה אישית, בספקים של צד שלישי או באירועים ישירים מ-Pub/Sub.
  • מטען ייעודי (payload) של אירוע בפורמט JSON גדול יותר ממטען ייעודי בפורמט Protobuf, ויכול להיות שזה ישפיע על המהימנות, בהתאם ליעד של האירוע ולמגבלות שלו על גודל האירוע. מידע נוסף זמין במאמר בנושא בעיות מוכרות.

יעדי יעד כמו פונקציות Cloud Run,‏ Cloud Run ו-GKE צורכים אירועים בפורמט HTTP. במקורות של Workflows, שירות Workflows ממיר את האירוע לאובייקט JSON ומעביר את האירוע להרצת זרימת העבודה כארגומנט בזמן ריצה.

שימוש בדרך סטנדרטית לתיאור מטא-נתונים של אירועים מבטיח עקביות, נגישות וניידות. צרכני האירועים יכולים לקרוא את האירועים האלה ישירות, או שאתם יכולים להשתמש בספריות הלקוח של Cloud בשפות שונות (כולל C++‎,‏ C#‎,‏ Go,‏ Java,‏ Node.js,‏ PHP,‏ Python ו-Ruby) כדי לקרוא ולנתח את האירועים. יש גם קבוצה של CloudEvents SDKs שספציפיים לשפות מסוימות.

המבנה של גוף ה-HTTP לכל האירועים זמין במאגר Google CloudEvents ב-GitHub.

‫Eventarc מעביר אירועים בפורמט CloudEvents. אפשר לקרוא אירועים ישירות, או להשתמש בספריות או בערכות SDK של Google CloudEvents כדי לנתח את האירועים.
איור 2. ‫Eventarc מעביר אירועים בפורמט CloudEvents ליעדי אירועים. אפשר לקרוא את האירועים האלה ישירות, או להשתמש בערכות SDK של CloudEvents או בספריות של Google כדי לקרוא ולנתח את האירועים.

תאימות לאחור

‫Eventarc מחשיב את התוספת של המאפיינים והשדות הבאים כתואמים לאחור:

  • מאפייני סינון אופציונליים או מאפיינים לקריאה בלבד
  • שדות אופציונליים במטען הייעודי (payload) של האירוע

טריגרים של Eventarc

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

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

‫Eventarc תומך בטריגרים לסוגי האירועים הבאים:

אירועים ביומני ביקורת של Cloud‏ (CAL)
תיאוריומני הביקורת ב-Cloud מספקים יומני ביקורת של פעילות האדמין וגישה לנתונים לכל פרויקט בענן, תיקייה וארגון. שירותי Google Cloud כותבים רשומות ביומנים האלה. אפשר ליצור מסננים לטריגרים של Eventarc באמצעות הערכים serviceName ו-methodName ביומני הביקורת. כדי לראות את הערכים המדויקים, אפשר לעיין במאמר שירותיGoogle Cloud עם יומני ביקורת. מידע נוסף זמין במאמר בנושא קביעת מסנני אירועים ליומני ביקורת של Cloud.
סוג מסנן האירועיםטריגרים של Eventarc עם type=google.cloud.audit.log.v1.written שולחים בקשות לשירות או לתהליך העבודה שלכם כשנוצר יומן ביקורת שתואם לקריטריוני הסינון של הטריגר.
אירועים ישירים
תיאוראפשר להפעיל את Eventarc באמצעות מגוון אירועים ישירים, כמו עדכון של קטגוריה ב-Cloud Storage, עדכון של תבנית של הגדרת תצורה מרחוק ב-Firebase או שינויים במשאבים בשירותי Google Cloud .

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

סוג מסנן האירועיםטריגרים של Eventarc עם סוגים ספציפיים של מסנני אירועים שולחים בקשות לשירות או לתהליך העבודה כשמתרחש אירוע שתואם לקריטריוני המסנן של הטריגר. לדוגמה, type=google.cloud.storage.object.v1.finalized (כשנוצר אובייקט בקטגוריה של Cloud Storage) או type=google.cloud.pubsub.topic.v1.messagePublished (כשמתפרסמת הודעה בנושא Pub/Sub שצוין).

מיקום הטריגר

Google Cloud שירותים כמו Cloud Storage יכולים להיות אזוריים או מרובי-אזוריים. אפשר להגדיר שירותים מסוימים, כמו Cloud Build, באופן גלובלי.

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

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

אפשר לציין מיקומי טריגר באמצעות הדגל --location בכל פקודה. במקרים של יעדים ב-Cloud Run, אם לא מציינים את האפשרות --destination-run-region, המערכת מניחה שהשירות נמצא באותו אזור כמו הטריגר. מידע נוסף זמין במאמרי העזרה של Google Cloud CLI.

אמינות ומסירה

אלה הציפיות לגבי משלוחים:

  • האירועים מועברים באמצעות יומני הביקורת של Cloud תוך פחות מדקה. (הערה: למרות שטריגר של יומני ביקורת ב-Cloud נוצר באופן מיידי, יכול להיות שיעברו עד שתי דקות עד שהטריגר יופעל ויסנן את האירועים).
  • אירועים באמצעות Pub/Sub מועברים תוך שניות.

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

זמן האחזור והתפוקה הם על בסיס המאמץ הכי טוב. הם משתנים בהתאם למספר גורמים, כולל האם הטריגר של Eventarc הוא אזורי, רב-אזורי או גלובלי, ההגדרה של שירות מסוים ועומס הרשת על משאבים באזור Google Cloud .

חשוב לזכור שיש מכסות ומגבלות שימוש שחלות באופן כללי על Eventarc. יש גם מכסות ומגבלות שימוש שספציפיות ל-Workflows.

מדיניות ניסיון חוזר של אירועים

מאפייני הניסיון החוזר של Eventarc זהים לאלה של שכבת התעבורה שלו, Cloud Pub/Sub. משך השמירה של ההודעות שמוגדר כברירת מחדל על ידי Eventarc הוא 24 שעות עם השהיה מעריכית לפני ניסיון חוזר (exponential backoff).

אפשר לעדכן את מדיניות הניסיון החוזר דרך מינוי Pub/Sub שמשויך לטריגר Eventarc. מידע נוסף זמין במאמר בנושא ניסיון חוזר לשליחת אירועים.

ניראות (observability)

‫Google Cloud Observability מספקת כלים למעקב, לרישום ביומן ולאבחון. הכלים האלה יכולים לעזור לכם לעקוב אחרי הפעילות והצמיחה של Eventarc ולנתח אותן, וגם להבין את ההתנהגות, התקינות והביצועים של האפליקציות שלכם. מידע נוסף זמין במאמר בנושא יכולת צפייה ב-Eventarc.

יומנים מפורטים של Eventarc,‏ Cloud Run,‏ פונקציות Cloud Run,‏ GKE,‏ Pub/Sub ו-Workflows זמינים ביומני ביקורת של Cloud.

תוכנית התאוששות מאסון (DR)

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

תקני תאימות

‫Eventarc Standard עומד בדרישות של תקנים ואישורים ספציפיים. כדי להימנע משימוש במשאבי Eventarc Advanced שלא עומדים בדרישות, אפשר ליצור מדיניות ארגונית בהתאמה אישית שמשביתה את משאבי Eventarc Advanced. מידע נוסף זמין במאמר בנושא השבתה של משאבים מתקדמים ב-Eventarc.

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