ניווט בנוף שערי ה-API

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

ניתן לתפוס API Gateways כפרוקסי הפוך משודרג שמציע גמישות ויכולות אוטומציה רבות יותר מפרוקסי הפוך רגיל. הפופולריים ביותר מבוססים על Envoy, HAProxy ו-NGINX.

במאמר זה אבחן API Gateways בהקשר של ארכיטקטורות מודרניות, המשולבות באופן הדוק עם שירותי ענן אחרים או הפועלות באופן מקורי בתוך מרחב Kubernetes הפופולרי יותר ויותר.

יכולות ליבה שעלינו לצפות:

• ניתוב תעבורת רשת,
• הגבלת קצב,
• מטמון,
• ניטור,
• הרשאה ואימות,
• העשרת מטען,
• סיום SSL,
• circuit breaking,
• איזון עומסים,
• ניהול גישה בתשלום ל-API.

זרימת תעבורת רשת טיפוסית עם API Gateway פרוס

גישת Backend for frontend

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

שימוש במספר שערי API

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

מימושים פופולריים להרצה בתוך Kubernetes:

• שגריר,
• Kong,
• Traefik,
• Spring Cloud Gateway.

ספקי ענן פופולריים כוללים:

• Apigee,
• Azure API Management,
• Amazon API Gateway.

חלק מהחברות שפיתחו ESBs נכנסו גם הן ל שוק שערי API. דוגמה ל-ESB, אשר מספק תכונות API Gateway הוא MuleSoft ESB.

היזהרו מ-ESB המתחזים ל-API Gateways

במקום להרחיב בעצמי, הבה נבחן המלצות ממומחי התעשייה:

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

Clemens Vaster, ארכיטקט ב-Azure Service Bus צוות

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

Thoughtworks, Technology Radar כרך 234

זהו איזה סגנון ארכיטקטורה ברצונכם ליישם

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

תצורה לדוגמה

דוגמה לתצורה דקלרטיבית של כלל ניתוב ב-Open Source Ambassador/Emissary Gateway:

kind: Service apiVersion: v1 metadata: name: your-api labels: app: your-api service: your-api annotations: getambassador.io/config: | --- apiVersion: ambassador/v1 kind: Mapping name: your-api_mapping prefix: /your-api/ service: your-api:8080 timeout_ms: 15000 spec: type: ClusterIP selector: app: your-api ports: - name: http port: 8080

תצורה זו פשוט תקלוט בקשה עם הקידומת "your-api", תסיר אותה ותעביר את הבקשה אל Your API Kubernetes Service.

Emissary התקבל לאחרונה כאחד ה- פרויקטים של Cloud Native Computing Foundation. ישנם רבים של פרויקטים מעניינים ב-Cloud Native הנתמכים על ידי CNCF, אני ממליץ לעקוב אחר האתר שלהם: https://www.cncf.io/

כמה טיפים ליישום מוצלח

נפרט מספר נקודות כיצד להשתמש ב-API Gateways תוך מחשבה על עמידות ותחזוקתיות:

• רכיב כזה הוא בדרך כלל נקודת כשל יחידה; אם תכניסו כמה אלמנטים קטנים של לוגיקה עסקית, אתם מסתכנים בשבירת הפלטפורמה כולה, ולא רק שירות ה-backend שאליו ה- מתייחס לשינוי הנתון.
• במערכות אקולוגיות גדולות שבהן ה-Backend שלכם מורכב מעשרות או מאות מיקרו-שירותים, צוותים המבצעים שינויים באזור שלהם לא אמורים להיות בעלי האפשרות לשבור את ה-API של צוותים אחרים, דבר שעלול להיגרם מהכנסת לוגיקה מותאמת אישית כלשהי בתוך ה-Gateway שלנו.
• חלק משערי API פופולריים דורשים פריסה של מספר רכיבים, שקלו כיצד הדבר משפיע על ה-SLA שלכם.
• אם ה-Kubernetes Ingress Gateway שלכם אכן דורש מסד נתונים כדי לפעול, עליכם להפוך למומחים בעומסי עבודה stateful בתוך ה- מרחב Kubernetes.
• ניתן לאמת אישורים נכנסים ב-API Gateway, אך אין זה אומר ששירות ה-backend שלכם לא צריך גם לבדוק אותם – תמיד יש ליישם מדיניות אמון מינימלית.
• בחרו פתרונות שניתן לנהל באמצעות תצורה דקלרטיבית.
• כל צוות יכול לנהל את התצורה שלו ללא ה- סיכון לשבירת ממשקי API אחרים.
• שקול את קלות הפיתוח המקומית; אם עליך להריץ API Gateway כדי לבדוק את המיקרו-שירות שלך באופן מקומי, ראה זאת ככישלון.
• צמצמו את שטח הכשל ככל האפשר.
• יש לפעול לפי הגישה של "נקודות קצה חכמות, צינורות טיפשים".

אני גם ממליץ בחום על הרצאת צוות הטכנולוגיה של Netflix הזמינה ב-YouTube: שליטה בכאוס – מדריך של Netflix למיקרו-שירותים.

שאלות נפוצות