Apigee Hybrid מאפשר לכם לנהל ממשקי API באופן מקומי, ב-Google Cloud או בשילוב של שניהם:
ניהול כל ממשקי ה-API במקום אחד |
Apigee Hybrid עוזר לכם לנהל ממשקי API פנימיים וחיצוניים באמצעות Google Cloud. בעזרת ניהול מאוחד של API, אתם יכולים לספק למפתחים, לשותפים וללקוחות שלכם חוויה עקבית של תוכנית API. |
אבטחה ותאימות |
אם שיקולי התאימות והאבטחה מחייבים פריסה מקומית של האפליקציות שלכם, תוכלו לארח ולנהל את מישור זמן הריצה של Apigee Hybrid במקום, באמצעות שער היברידי ברמה שמתאימה לארגונים. אתם מנהלים ושולטים בזמן הריצה, כך שתוכלו להשתמש בתשתית הקיימת שלכם לצורך תאימות, ניהול ואבטחה. |
תמיכה באסטרטגיית מולטי-ענן |
כדי לאזן בין עלות לביצועים, יכול להיות שתבחרו באסטרטגיה היברידית. בין אם אתם רק בודקים ספקי שירותי ענן שונים או שכבר בחרתם באסטרטגיה היברידית, פלטפורמת ניהול ה-API שלכם צריכה לספק לכם את הגמישות שאתם צריכים. אירוח וניהול של שערים היברידיים ברמת הארגון במרכז הנתונים, ב-Google Cloud או בשניהם. |
|
אם רוצים לקבל מידע נוסף על שימוש בשיטה היברידית:
|
אם אתם מוכנים להתקין את הגרסה ההיברידית:
|
תוכניות API בעולם היברידי
Apigee Hybrid מורכב ממישור ניהול שמתוחזק על ידי Google וממישור זמן ריצה שמתקינים ב-Kubernetes בתשתית מקומית או ב-Google Cloud. שני המישורים משתמשים בשירותי Google Cloud Platform, כמו שמוצג בתמונה הבאה:
כפי שאפשר לראות, הפתרון ההיברידי כולל את הרכיבים העיקריים הבאים:
- מישור הניהול שמופעל על ידי Apigee: קבוצה של שירותים שמתארחים בענן ומתוחזקים על ידי Google. השירותים האלה כוללים את ממשק המשתמש, ממשק הניהול של ה-API והניתוח.
מישור זמן ריצה בניהול הלקוח: קבוצה של שירותי זמן ריצה מבוססי-קונטיינרים שאתם מגדירים ומתחזקים באשכול Kubernetes משלכם. כל התנועה ב-API עוברת דרך מישור זמן הריצה ומעובדת בו.
אתם מנהלים את זמן הריצה של הקונטיינר באשכול Kubernetes כדי לשפר את הגמישות באמצעות השקות מדורגות, התאמה אוטומטית לעומס והטבות תפעוליות אחרות של קונטיינרים.
- Google Cloud: חבילה של שירותי ענן שמארחת Google.
חשוב לדעת שבסביבה היברידית, כל התעבורה של ה-API מעובדת בגבולות הרשת שלכם ובשליטתכם, בעוד ששירותי הניהול, כמו ממשק המשתמש וניתוח ה-API, פועלים בענן ומתוחזקים על ידי Google. מידע נוסף זמין במאמר איפה הנתונים שלכם מאוחסנים?
בסרטון הבא מוסבר לעומק על הארכיטקטורה ההיברידית:
מידע על מישור זמן הריצה
מישור זמן הריצה הוא קבוצה של שירותי זמן ריצה מבוססי-קונטיינרים שאתם מגדירים ומתחזקים באשכול Kubernetes משלכם. כל התנועה ב-API עוברת דרך מישור זמן הריצה ומעובדת בו. מישור זמן הריצה כולל את הרכיבים העיקריים הבאים:
מישור זמן הריצה פועל באשכול Kubernetes שבבעלותכם ושאתם מתחזקים.
בתמונה הבאה מוצגים השירותים העיקריים שפועלים במישור זמן הריצה:
מידע כללי על רכיבי זמן הריצה מופיע בקטעים הבאים. בנוסף, אפשר לעיין במאמר סקירה כללית על הגדרת שירות זמן הריצה.
בקטעים הבאים מפורטים כל אחד משירותי מישור זמן הריצה הראשיים האלה.
מעבד בקשות
מעבדי הודעות (MP) היברידיים מספקים עיבוד של בקשות API וביצוע של מדיניות במישור זמן הריצה. מעבדי ההודעות טוענים את כל ה-proxies, המשאבים, שרתי היעד, האישורים ומאגרי המפתחות שנפרסו מאחסון מקומי. אתם מגדירים בקר Istio Ingress כדי לחשוף את מעבדי ההודעות לבקשות שמגיעות מחוץ לאשכול.
Synchronizer
הכלי Synchronizer מאחזר נתוני תצורה לגבי סביבת API ממישור הניהול ומפיץ אותם במישור זמן הריצה. הנתונים האלה שהורדו נקראים גם חוזה והם מאוחסנים במערכת הקבצים המקומית.
הכלי לסנכרון שולח מדי פעם בקשות לשרת הניהול כדי לבדוק אם יש שינויים, ומוריד הגדרה חדשה בכל פעם שמזוהים שינויים. נתוני ההגדרה מאוחזרים ונשמרים באופן מקומי כקובץ JSON במערכת הקבצים המקומית, שמעבדי ההודעות יכולים לגשת אליה.
נתוני התצורה שהורדו מאפשרים למישור זמן הריצה לפעול באופן עצמאי ממישור הניהול. במסגרת החוזה, מעבדי ההודעות במישור זמן הריצה משתמשים בנתונים שמאוחסנים באופן מקומי כהגדרה שלהם. אם החיבור בין רמת הניהול לבין רמת זמן הריצה מפסיק לפעול, השירותים ברמת זמן הריצה ממשיכים לפעול.
נתוני התצורה שהכלי לסנכרון מוריד כוללים:
- חבילות של שרתי proxy ופריסות של תהליכי עבודה משותפים
- קטעי הוק (hooks) לזרימה
- מידע על הסביבה
- משאבי API משותפים
- הגדרות של שרת היעד
- הגדרות TLS
- שמות של מפות מפתח/ערך (KVM)
- מסכות נתונים
מאגר נתונים של Cassandra
Apache Cassandra הוא מאגר הנתונים בזמן הריצה שמספק עמידות של הנתונים למישור זמן הריצה.
Cassandra היא מערכת נתונים מבוזרת שמספקת עמידות נתונים במישור זמן הריצה. אתם פורסים את מסד הנתונים של Cassandra כמאגר צמתים של StatefulSet באשכול Kubernetes. המיקום של הישויות האלה קרוב לשירותי העיבוד בזמן הריצה, ועוזר לעמוד בדרישות של אבטחה ומדרגיות גבוהה.
במסד הנתונים של Cassandra מאוחסן מידע על הישויות הבאות:
- מערכת ניהול מפתחות (KMS)
- Key Value Map (KVM)
- מטמון תגובות
- OAuth
- מכסות
Management API for Runtime data (MART)
נתונים ששייכים לארגון שלכם ושיש אליהם גישה במהלך קריאות ל-API של זמן הריצה מאוחסנים על ידי Cassandra במישור זמן הריצה.
הנתונים האלה כוללים:
- הגדרות אפליקציה
- נתונים של מערכת ניהול מפתחות (KMS)
- מטמון
- מפות מפתח/ערך (KVM)
- מוצרי API
- אפליקציות למפתחים
כדי לגשת לנתונים האלה ולעדכן אותם – למשל, כדי להוסיף KVM חדש או להסיר סביבה – אפשר להשתמש בממשק המשתמש של Apigee hybrid או ב-Apigee APIs. שרת ה-MART (Management API for Runtime data) מעבד את קריאות ה-API מול מאגר הנתונים של זמן הריצה.
בסעיף הזה מוסבר התפקיד של MART כשקוראים לממשקי Apigee API כדי לגשת למאגר הנתונים של זמן הריצה.
| מה זה MART | כדי לבצע קריאה ל-Apigee API, שולחים בקשה מאומתת לשרת הניהול (MS) במישור הניהול. ה-MS מאמת ומאשר את הבקשה, ואז מעביר אותה ל-MART במישור זמן הריצה. לבקשה הזו מצורף טוקן שה-MS יצר באמצעות חשבון שירות שהוגדר מראש. הבקשה מתקבלת ב-MART, עוברת אימות ואישור, ואז מתבצעת בה בדיקת תוקף של העסק. (לדוגמה, אם האפליקציה היא חלק ממוצר API, MART מוודא שהבקשה תקינה). אחרי שנקבע שהבקשה תקפה, MART מעבד אותה. Cassandra מאחסן את נתוני זמן הריצה שמעובדים על ידי MART (הוא מאגר נתונים של זמן ריצה). יכול להיות ש-MART יקרא נתונים מ-Cassandra או שיעדכן את הנתונים האלה, בהתאם לסוג הבקשה. בדומה לרוב השירותים ההיברידיים, MART הוא חסר מצב: הוא לא שומר את המצב שלו בזמן הריצה. |
| מה MART לא | למרות ש-MART חושף יציאה לענן הציבורי, לא מתקשרים ל-MART ישירות. (היציאה צריכה להיות חשופה כדי ש-MART יוכל לקבל קריאות מה-MS דרך חשבון שירות). בנוסף, MART לא מקבל קריאות בזמן ריצה מהלקוחות שלכם לשרתי ה-proxy של ה-API שלהם. הקריאות האלה מטופלות על ידי בקר הכניסה (ingress) ומועברות למעבדי ההודעות של האשכול שלכם. |
חשוב לציין של-MART ולמעבדי ההודעות יש גישה לאותו מאגר נתונים בזמן ריצה (Cassandra), וכך נתונים כמו KMS, KVM ומטמון משותפים.
בתמונה הבאה מוצג התהליך של קריאה ל-API של Apigee:
UDCA
הסוכן האוניברסלי לאיסוף נתונים (UDCA) הוא שירות שפועל בתוך יחידת איסוף הנתונים (pod) במישור זמן הריצה. הוא מחלץ נתונים של ניתוח, ניפוי באגים וסטטוס פריסה, ושולח אותם אל UAP.
מידע נוסף מופיע במאמר איסוף נתונים לצורך ניפוי באגים, ניתוח וסטטוס פריסה.
מידע על מישור הניהול
מישור הניהול פועל ב-Google Cloud. הוא כולל שירותים אדמיניסטרטיביים כמו:
- ממשק משתמש של Apigee Hybrid: ממשק משתמש למפתחים ליצירה ולפריסה של שרתי proxy ל-API, להגדרת מדיניות, ליצירת מוצרי API וליצירת אפליקציות למפתחים. אדמינים יכולים להשתמש בממשק המשתמש של Apigee hybrid כדי לעקוב אחרי סטטוס הפריסה.
- ממשקי API של Apigee: מספקים ממשק פרוגרמטי לניהול הארגון והסביבות.
- פלטפורמת ניתוח מאוחדת (UAP): מקבלת ומעבדת נתוני ניתוח ונתוני סטטוס פריסה ממישור זמן הריצה.
בתמונה הבאה מוצגים השירותים העיקריים שפועלים במישור הניהול:
מידע על שירותי Google Cloud
בטבלה הבאה מתוארים שירותי Google Cloud העיקריים שמשמשים בפתרון היברידי:
| שירות Google Cloud | תיאור |
|---|---|
| זהות | האימות של חשבון המשתמש מתבצע באמצעות חשבונות Google Cloud. ההרשאה מתבצעת באמצעות חשבונות שירות ב-Google Cloud. |
| תפקידים | ניהול הגישה ב-Hybrid משתמש במנוע התפקידים של Google, ב-IAM ותומך בתפקידי ברירת המחדל של Apigee. |
| היררכיית המשאבים | המשאבים מאורגנים בפרויקטים ב-Google Cloud (שמקושרים לארגונים ב-Apigee). |
| Stackdriver | ניתוח של נתוני יומנים ומדדים. |
סוגי משתמשים
Apigee זיהתה את הסוגים העיקריים הבאים של משתמשי Hybrid:
| תפקיד | תחומי אחריות או משימות אופייניים | תחומי עניין |
|---|---|---|
| אדמינים/מפעילים של המערכת |
|
|
| מפתחים |
|
|
יתרונות
ל-Apigee Hybrid יש את היתרונות הבאים:
- גמישות מוגברת
- מכיוון ש-Hybrid מועבר ופועל בקונטיינרים, אתם יכולים לבצע השקות מדורגות, להגדיר התאמה אוטומטית לעומס וליהנות מיתרונות תפעוליים אחרים של מערכת מבוססת-קונטיינרים.
- זמן אחזור מופחת
- כל התקשורת עם מישור הניהול ההיברידי היא אסינכרונית ולא מתרחשת כחלק מעיבוד בקשות API של לקוחות.
- שימוש נרחב יותר ב-API
- אפשר לעבד ממשקי API פנימיים באמצעות Apigee, אבל זמן האחזור המופחת והיעילות שניתן להשיג באמצעות פתרון היברידי הופכים את העיבוד של ממשקי API פנימיים באמצעות פתרון היברידי לאפשרות אטרקטיבית. היעילות הזו מושגת בין היתר כי שער ה-API שלכם פועל בפריסה מקומית, בקרבה לשירותי ה-Backend. בנוסף, אם אתם משתמשים ב-Apigee, אתם יכולים להגדיל את השימוש ב-Apigee על ידי עיבוד ממשקי API פנימיים באמצעות hybrid.
- שליטה רבה יותר
- ארגונים רבים יוצאים לדרך עם אסטרטגיה היברידית. היכולת לנהל זמני ריצה של API שנפרסו במרכזי נתונים פרטיים היא דרישה מרכזית לארגונים גדולים. בשלב הזה, אפשר לפרוס את מישור זמן הריצה ההיברידי ב-Google Cloud או במרכז הנתונים שלכם.
השלב הבא
סקירה כללית של תהליך ההתקנה ההיברידית מופיעה במאמר התמונה הגדולה.