Endpoints היא מערכת מבוזרת לניהול API שכוללת שירותים, סביבות זמן ריצה וכלים. Endpoints מספק ניהול, מעקב ואימות.
הרכיבים שמהם מורכבות נקודות הקצה הם:
Extensible Service Proxy (ESP) או Extensible Service Proxy V2 (ESPv2) – להטמעת פונקציונליות של Endpoints.
Service Control – להחלת כללים של ניהול API.
ניהול שירותים – להגדרת כללים לניהול API.
Google Cloud CLI – לפריסה ולניהול.
Google Cloud console – לרישום ביומן, למעקב ולשיתוף.
ארכיטקטורה של נקודות קצה
רכיבים של נקודות קצה
ESP
ESP הוא שרת proxy מבוסס NGINX שפועל מול ה-Backend ומזריק פונקציונליות של Endpoints כמו אימות, מעקב ורישום ביומן. ESP מאחזר הגדרת שירות מ-Service Management ומשתמש בה כדי לאמת בקשות נכנסות.
ESP מיועד לפריסה בסביבה מבוססת-קונטיינרים ולאימות של אסימוני JWT ואסימוני מזהה של Google. הוא משתמש במגוון טכניקות, כמו שמירת נתונים במטמון וקריאות אסינכרוניות, כדי לשמור על משקל קל ועל ביצועים גבוהים.
התמיכה ב-ESP זמינה בפלטפורמות הבאות:
ESPv2
ESPv2 הוא פרוקסי מבוסס Envoy, בעל ביצועים גבוהים וניתן להרחבה, שפועל מול קצה עורפי של OpenAPI או gRPC API. נקודות הקצה ב-ESPv2 תומכות בגרסה 2 של מפרט OpenAPI ובמפרטים של gRPC.
ESPv2 משולב עם Google Service Infrastructure כדי להפעיל תכונות של ניהול API בהיקף נרחב, כולל אימות, דוחות טלמטריה, מדדים ואבטחה.
התמיכה ב-ESPv2 זמינה בפלטפורמות הבאות:Service Control API
Service Control API מחיל כללים לניהול API בזמן ריצה, כמו אימות מפתח, מעקב ורישום ביומן. ב-Service Control זמינות השיטות הבאות:
Check – מאמת את מפתחות ה-API והאימות, ומציין אם צריך לאפשר קריאה
דיווח – מודיע למערכות הרישום על רישום ביומן וניטור
ניהול השירות
אתם מתארים את ההתנהגות של שירות ה-gRPC בקובץ YAML שנקרא הגדרת נקודות הקצה (Endpoints). פורסים את ההגדרה של Endpoints ואת קובצי ה-.proto שעברו קומפילציה ב-Service Management באמצעות ה-CLI של gcloud, שמגדיר את כללי ניהול ה-API.
כאן מתבצעות גם משימות אחרות שקשורות להגדרות, כמו שיתוף ה-API עם מפתחים אחרים, הפעלה או השבתה של ה-API בפרויקטים שונים ויצירה של מפתחות API.
ה-CLI של gcloud
ה-CLI של gcloud מספק את ה-CLI של Google Cloud שבו אפשר להשתמש כדי לבצע קריאות לשירותים שונים של Google Cloud . משתמשים ב-Google Cloud CLI כדי לפרוס את ההגדרה של Endpoints ב-Service Management.
מסוףGoogle Cloud
מסוףGoogle Cloud הוא ממשק המשתמש הגרפי שלGoogle Cloud. Endpoints משתמש ב-Google Cloud Console כדי לחשוף נתוני מעקב ורישום ביומן שנשלחים מ-ESP או מ-ESPv2 ונרשמים על ידי Service Control API ו-Share API עם מפתחים אחרים, וכדי לאפשר להם ליצור מפתחות API כדי לקרוא ל-API.
תרחישי פריסה
אפשרויות הפריסה משתנות בהתאם לשימוש ב-ESP או ב-ESPv2 כשרת proxy של Endpoints. אפשר לפרוס את ESPv2 כפרוקסי מרוחק, ואפשר לפרוס את ESPv2 ואת ESP במצב sidecar, כמו שמוסבר בקטעים הבאים.
מצב שרת proxy מרחוק
אם משתמשים ב-ESPv2, אפשר לפרוס את Endpoints כשרת proxy מרוחק. השימוש במצב הזה נועד לתמוך באפליקציות שפועלות בפלטפורמות ללא שרתים, כמו Cloud Run, פונקציות Cloud Run ו-App Engine לסביבות רגילות.
במצב הזה, ESPv2 נפרס כאפליקציית Cloud Run. האפליקציה מוגדרת להשתמש ב-ESPv2 כקצה עורפי מרוחק באמצעות השדה x-google-backend בהגדרת שירות OpenAPI. כש-ESPv2 פועל כשרת proxy מרוחק במצב הפריסה הזה, הוא יכול לתמוך במספר שרתים מרוחקים בעורף.
מצב Sidecar
ESP ו-ESPv2 תומכים בפריסה בקונטיינר לצד כל מופע של ה-Backend. טופולוגיה מקומית של השרת מתאימה גם לממשקי API שפונים לאינטרנט וגם למיקרו-שירותים. הוא מאפשר ניהול API עם ביצועים גבוהים ועם יכולת הרחבה, ומונע את הניתוב ברשת שקשור בדרך כלל לשרתי proxy מרכזיים.
בדרך כלל, איזון העומסים מופעל לפני שהתנועה מגיעה ל-ESP או ל-ESPv2. ב-Compute Engine, האיזון מתבצע באמצעות Cloud Load Balancing. בפריסות של Kubernetes, אפשר להשתמש בשרת proxy של Ingress לאיזון עומסים. ב-Google Kubernetes Engine, אפשר להשתמש ב-Cloud Load Balancing או ב-ingress proxy לאיזון עומסים.
בזמן ההפעלה, ESP או ESPv2 מקבלים את הגדרת השירות מ-Service Management. הגדרת השירות נוצרת ממפרט OpenAPI או מ-gRPC, קובץ ה-YAML של הגדרת השירות. הוא מציין ל-ESP או ל-ESPv2 את ממשק ה-API לניהול, יחד עם המדיניות, כמו השיטות שדורשות אימות והשיטות שדורשות מפתחות API.
ניתוב בקשות
כשמתקבלת בקשה, ESP או ESPv2 יוצרים אסימון מעקב עבור Cloud Trace.
לאחר מכן, ESP או ESPv2 משווים את הנתיב של הבקשות הנכנסות לממשק של ה-API. אחרי שהמערכת מוצאת נתיב תואם, ספק ה-ESP או ESPv2 מבצעים את שלבי האימות של השיטה שצוינה.
אם נדרש אימות JWT, ESP או ESPv2 מאמתים את האימות באמצעות המפתח הציבורי המתאים של החותם, ומאמתים את שדה הקהל ב-JWT. אם נדרש מפתח API, ESP או ESPv2 מבצעים קריאה ל-Service Control API כדי לאמת את המפתח.
Service Control API מחפש את המפתח כדי לאמת אותו, ומוודא שממשק ה-API הופעל בפרויקט שמשויך למפתח. אם המפתח לא תקין או שה-API לא הופעל בפרויקט, הקריאה נדחית והיא נרשמת ביומן באמצעות Service Control API.
אם Service Control API מאמת את המפתח בהצלחה, הבקשה מועברת אל ה-backend יחד עם כל הכותרות המקוריות, בתוספת כותרת אימות JWT, אם רלוונטי.
כשמתקבלת תשובה מהקצה העורפי, ESP או ESPv2 מחזירים את התשובה למתקשר ושולחים את פרטי התזמון הסופיים ל-Trace. נקודות הקריאה מתועדות על ידי Service Control API, שכותב מדדים ויומנים ליעדים המתאימים.
ESP או ESPv2 ב-Kubernetes
בתרשים הבא מוצגת הארכיטקטורה הכוללת שבה ESP פועל כקונטיינר sidecar לפני קונטיינר אפליקציית שירות ה-API, כאשר my-api API מתארח ב-my-api.com ומגובה על ידי שירות Kubernetes. הארכיטקטורה תהיה זהה לפריסת sidecar עם ESPv2.
