הדף הזה רלוונטי ל-Apigee ול-Apigee Hybrid.
לעיון במסמכי התיעוד של
Apigee Edge
בנושא הזה מוסבר על ארכיטקטורת המערכת של Apigee. הוא נועד לעזור לכם להבין אילו רכיבים נוצרים במהלך הקצאת הרשאות ואת המטרה שלהם במערכת הכוללת.
ב-Apigee יש שתי אפשרויות להקצאת משאבים: עם קישור בין רשתות VPC ובלי קישור בין רשתות VPC. שתי האפשרויות מתוארות בקטעים הבאים.
ארכיטקטורה עם קישור בין רשתות VPC שכנות (peering)
בקטע הזה מתוארת ארכיטקטורת המערכת של Apigee כש-Apigee מוקצה עם האפשרות של צימוד VPC.
סקירה כללית על הקצאת הרשאות
במהלך ההקצאה, רכיבים מוגדרים ונוצרים כדי לאפשר תקשורת דו-כיוונית בין רשת של ענן וירטואלי פרטי (VPC) שמנוהלת על ידכם לבין רשת VPC שמנוהלת על ידי Apigee. אחרי שמסיימים את כמה השלבים הראשונים של הקצאת הרשאות, שני ה-VPC קיימים, אבל עדיין לא יכולים לתקשר אחד עם השני. כדי לאפשר תקשורת דו-כיוונית, צריך לבצע הגדרות נוספות. ראו איור 1.
כדי לאפשר תקשורת בין רשתות VPC, אנחנו משתמשים בקישור בין רשתות VPC שכנות (peering). קישור בין רשתות מאפשר קישוריות של כתובות IP פנימיות בין שתי רשתות של ענן וירטואלי פרטי (VPC), בלי קשר לשאלה אם הן שייכות לאותו פרויקט או לאותו ארגון ב-Google Cloud. אחרי שמסיימים את השלב של קישור בין רשתות שכנות (peering), אפשר ליצור תקשורת בין שני ה-VPC. ראו איור 2.
כדי לנתב תנועה מאפליקציות לקוח באינטרנט אל Apigee, אנחנו משתמשים במאזן עומסים חיצוני של אפליקציות (XLB). XLB יכול לתקשר בין פרויקטים ב-Google Cloud, למשל בין פרויקט Google Cloud של הלקוח לבין פרויקט Google Cloud של Apigee, באמצעות הפניה לשירותים בין פרויקטים.
אפשר גם להקצות קבוצת מופעים מנוהלת (MIG) של מכונות וירטואליות (VM) שמשמשות כגשר רשת. למכונות הווירטואליות ב-MIG יש יכולת לתקשר דו-כיוונית בין הרשתות המקושרות. כשסיום ההקצאה, אפליקציות באינטרנט מתקשרות עם ה-XLB, ה-XLB מתקשר עם המכונה הווירטואלית של הגשר, והמכונה הווירטואלית של הגשר מתקשרת עם רשת Apigee. ראו איור 3 ואיור 4.
בהגדרה הזו, תעבורת הנתונים מנותבת מ-Apigee (לדוגמה, ממדיניות MessageLogging) לעומס עבודה שפועל ב-VPC הפנימי. במקרה כזה, התקשורת עם ה-VPC הפנימי לא עוברת דרך כתובת IP של NAT של יציאה. במקום זאת, אפשר לנתב את התנועה דרך אחד מכתובות ה-IP של מופע Apigee.
מחזור החיים של קריאה ל-proxy ל-API
באיור הבא מוצג מחזור החיים של קריאה ל-proxy ל-API כשהיא עוברת דרך רכיבי המערכת המוקצים של Apigee (איור 5):
- אפליקציית לקוח שולחת קריאה ל-proxy ל-API ב-Apigee.
- הבקשה מגיעה למאזן עומסים חיצוני גלובלי ברמה 7 (XLB) מסוג HTTPS. ה-XLB מוגדר עם כתובת IP חיצונית/ציבורית ואישור TLS.
- ה-XLB שולח את הבקשה למכונה וירטואלית (VM). המכונה הווירטואלית משמשת כגשר בין ה-VPC שלכם לבין ה-VPC של Google (שמנוהל על ידי Apigee).
- המכונה הווירטואלית שולחת את הבקשה ל-Apigee, שמטפל בבקשת ה-proxy ל-API.
- Apigee שולח את הבקשה לשירות הקצה העורפי, והתשובה נשלחת חזרה ללקוח.
ארכיטקטורה עם השבתה של קישור בין רשתות VPC שכנות (peering)
בקטע הזה מתוארת ארכיטקטורת המערכת של Apigee כשלא מוקצים משאבים ל-Apigee עם האפשרות של שיוך VPC.
במהלך ההקצאה, רכיבים מוגדרים ונוצרים כדי לאפשר תקשורת דו-כיוונית בין רשת של ענן וירטואלי פרטי (VPC) שמנוהלת על ידכם לבין רשת VPC שמנוהלת על ידי Apigee. אחרי שמסיימים את כמה השלבים הראשונים של הקצאת הרשאות, שני ה-VPC קיימים, אבל עדיין לא יכולים לתקשר זה עם זה. כדי לאפשר תקשורת דו-כיוונית, צריך לבצע הגדרות נוספות. ראו איור 6.
כדי לאפשר תקשורת בין רשתות VPC, אנחנו משתמשים ב-Private Service Connect כדי לנתב תנועה צפונה אל Apigee ותנועה דרומה אל שירותי היעד שפועלים בפרויקטים שלכם ב-Google Cloud.
Private Service Connect מאפשר חיבור פרטי בין בעלים של שירות מנוהל (Apigee) לבין צרכן השירות (פרויקט אחד או יותר בענן שאתם שולטים בו). בשיטה הזו (איור 7), הבקשות עוברות דרך מאזן עומסים של אפליקציות (ALB) חיצוני או דרך מאזן עומסים חיצוני אזורי לנקודת צירוף יחידה שנקראת צירוף שירות.
כדי לחבר את Apigee באופן פרטי ליעד בקצה העורפי, צריך ליצור שני ישויות: צירוף שירות ברשת ה-VPC שבה היעד פרוס וצירוף נקודת קצה ב-VPC של Apigee. שני הישויות האלה מאפשרות ל-Apigee להתחבר לשירות היעד. דפוסי רשתות יוצאות
השלבים להקצאת Apigee באמצעות Private Service Connect (בלי קישור בין רשתות VPC שכנות) מתוארים במאמר הקצאה באמצעות שורת פקודה בלי קישור בין רשתות VPC שכנות.
