מודל פריסה של API Gateway

מידע על רכיבי API

‫API שמוגדר ב-API Gateway מורכב משני רכיבים עיקריים:

  1. הגדרת API: הגדרת ה-API שנוצרת כשמעלים הגדרת API. אתם יוצרים את הגדרת ה-API כמפרט OpenAPI. אם ה-API שלכם מנהל שירותי gRPC ב-Cloud Run, אתם יכולים להגדיר את ה-API באמצעות הגדרה ותצורה של שירות gRPC.

    בכל פעם שמעלים הגדרת API, ‏ API Gateway יוצר הגדרת API חדשה. כלומר, אפשר ליצור הגדרת API אבל אי אפשר לשנות אותה מאוחר יותר. אם מאוחר יותר תערכו את הגדרת ה-API במפרט OpenAPI או בהגדרת שירות gRPC, ואז תעלו את הגדרת ה-API הערוכה, תיצרו הגדרת API חדשה.

  2. ‫Gateway: פרוקסי מבוסס Envoy, בעל ביצועים גבוהים וניתן להרחבה, שמארח את הגדרת ה-API שנפרסה. פריסת הגדרת API בשער יוצרת את כתובת ה-URL שמופנית כלפי חוץ, שבה לקוחות ה-API משתמשים כדי לגשת ל-API.

בתמונה הבאה מוצגים הרכיבים האלה:

הגדרת ה-API בחלונית API Gateway מציגה שלושה רכיבי הגדרת API ושלושה רכיבי שער.

מידע על פריסת הגדרות API בשער

פורסים הגדרת API לשער כדי להפוך את ה-API לנגיש ללקוחות ה-API:

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

שער:

  • הפריסה מתבצעת ב Google Cloud אזור ספציפי. אזור הוא מיקום גיאוגרפי ספציפי ב- Google Cloud שבו אפשר לפרוס משאבים.

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

  • אפשר לארח רק הגדרת API אחת. אי אפשר לפרוס כמה הגדרות API לאותו שער.

אחר כך מנהלים כל שער שנפרס בנפרד. לכל שער אפשר:

  • הפעלה/הפסקה/מחיקה של השער
  • צפייה ביומנים ובמדדים
  • הצגת פרטי ההעברה

בחירת Google Cloud אזור

כל שער נפרס באזור גיאוגרפי ספציפי ב- Google Cloud. ‫API Gateway תומך בפריסה ב Google Cloud אזורים הבאים:

  • asia-northeast1
  • australia-southeast1
  • europe-west1
  • europe-west2
  • us-east1
  • us-east4
  • us-central1
  • us-west2
  • us-west3
  • us-west4

הגדרת נקודת הקצה של תצורת ה-API שנפרסה

כשפורסים הגדרת API לשער, API Gateway יוצר כתובת URL ייחודית לשער בדומיין gateway.dev. לאחר מכן, לקוחות ה-API משתמשים בכתובת URL מהצורה הבאה כדי לגשת להגדרת ה-API שנפרסה:

https://GATEWAY_ID-HASH.REGION_CODE.gateway.dev

כאשר GATEWAY_ID הוא שם השער, HASH הוא קוד הגיבוב הייחודי שנוצר כשפרסתם את ה-API, ו-REGION_CODE הוא הקוד של המיקום בענן שבו פרסתם את השער.

לדוגמה:

my-gateway-a12bcd345e67f89g0h.uc.gateway.dev

הגדרת חשבון שירות לפריסת הגדרות API

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

בנוסף לתפקידים שנדרשים כדי לגשת לשירות לקצה העורפי, צריך לתת לחשבון השירות את ההרשאות הבאות:

  • ההרשאה iam.serviceAccounts.actAs. ההרשאה הזו כלולה בתפקיד משתמש בחשבון שירות.

  • ההרשאות שנדרשות כדי לגשת לשירות הקצה העורפי. לדוגמה, אם הקצה העורפי שלכם מיושם כ-Cloud Function, לחשבון השירות צריך להיות מוקצה לפחות התפקיד Cloud Functions Invoker. בקצה העורפי של Cloud Run, התפקיד הוא Cloud Run Invoker. הגבלת ההרשאות שמשויכות להגדרת ה-API מאפשרת לאבטח טוב יותר את המערכות בקצה העורפי.

מידע נוסף מופיע במאמר הגדרת סביבת הפיתוח.

מידע על צמצום הפעולה לאפס

‫API Gateway הוא שירות צמצום הפעולה לאפס. המשמעות היא שאם אין תנועה, כל המופעים של השער נמחקים. כשהתנועה גדלה, נוצרים מופעים חדשים על פי דרישה כדי לטפל בעומס. התכונה 'צמצום הפעולה לאפס' נשלטת אוטומטית על ידי Google Cloud, ולא נדרשת פעולה מצידכם כדי להגדיר או לנהל אותה.

שימוש במאזן עומסים

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

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

הגדרת גישת SSL ל-API

‫API Gateway תומך בגישת HTTPS ל-API שנפרס בשער. מכיוון שממשקי ה-API שלכם נפרסים בדומיין gateway.dev,‏ Google יוצרת ומנהלת את אישור ה-SSL במאזן העומסים שמשולב בשער. לא צריך ליצור או להעלות אישור משלכם.

הגדרת שרת שמות של דומיין

כברירת מחדל, לקוחות API שולחים בקשות לדומיין gateway.dev כדי לגשת ל-API שנפרס, כמו שמוצג למעלה.

שמות דומיין מותאמים אישית מיועדים ל-API Gateway כשמשתמשים בהם בשילוב עם איזון עומסים מסוג HTTP(S) עבור API Gatewayבגרסת Preview. כדי להתאים אישית את שם הדומיין, יוצרים מאזן עומסים לשימוש בשם הדומיין המותאם אישית, ואז מפנים בקשות לדומיין gateway.dev של ה-API שפרסתם. מידע נוסף זמין במאמר בנושא שימוש בדומיין מותאם אישית עם API Gateway.

פריסת כמה הגדרות API באותו API

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

בקטע הזה מתוארים שני תרחישים שבהם כדאי לפרוס כמה הגדרות API בכמה שערים ב-API יחיד.

פריסת הגדרות API לכמה שערים באותו אזור

כשמפתחים API, מפתחי API יוצרים לעיתים קרובות סביבות פיתוח, Staging וייצור, שבהן:

  • סביבת הפיתוח משמשת את המפתחים ליצירת ה-API.
  • סביבת ההכנה משמשת לבדיקת ה-API לקראת הפצה בסביבת הייצור.
  • בסביבת הייצור מותר ללקוחות חיצוניים של ה-API לגשת ל-API.

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

ב-API 1, שלוש הגדרות API בשם API Config Dev,‏ API Config Stage ו-API Config Prod נפרסות בשלושה שערים בהתאמה.

בדוגמה הזו יש שלוש הגדרות שונות של API: ‏ dev,‏ stage ו-prod. לאחר מכן פורסים כל הגדרת API בשער אחר, כאשר כל שער מגדיר כתובת URL ייחודית משלו לנקודת הקצה.

פריסת הגדרת API למספר אזורים

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

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

בתמונה הבאה, ממשקי API‏ 1 ו-2 נפרסים באזור יחיד, וממשק API‏ 3 נפרס במספר אזורים:

‫API 1 ו-API 2 נפרסים באזור 1, ו-API 3 נפרס באזורים 1, 2 ו-3 באמצעות מאזן עומסים.

בדוגמה הזו, לכל הגדרת API שנפרסה לשער עבור API 3 יש נקודת קצה ייחודית של כתובת URL, בצורה:

https://my-gateway1-a12bcd345e67f89g0h.uc.gateway.dev
https://my-gateway2-b12cde345f67g89h0i.en.gateway.dev
https://my-gateway3-c12bde345g67h89i0j.uw.gateway.dev

לאחר מכן מגדירים מאזן עומסים באמצעות איזון עומסים מסוג HTTP(S) ל-API GatewayPREVIEW כדי לטפל בבקשות ל-API ולהעביר את הבקשה לאזור המתאים. מידע נוסף מופיע במאמר בנושא יצירת פריסות מרובות אזורים ל-API Gateway.

עדכון API

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

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

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

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