הבנת דפוס שער ה-API בשירותי מיקרו: מדריך פשוט

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

אם יש לך עשרה, חמישים או מאות שירותים זעירים, האם אפליקציה או דף אינטרנט לנייד צריכים להתחבר ישירות לכל אחד מהם?

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

האנלוגיה של העולם האמיתי: פקידת הקבלה של המלון

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

• משק בית (לסדינים נקיים)
• שירות חדרים (לאוכל)
• קונסיירז’ (להזמנת סיורים)
• חיוב (עבור תשלום החשבון)

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

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

בתרחיש זה:

• אתה הוא הלקוח (אפליקציה לנייד או דפדפן).
• פקידת הקבלה היא API Gateway.
• המחלקות (משק בית, שירות חדרים, חיוב) הן שירותי המיקרו.

הבעיה: תקשורת ישירה בין לקוח לשירות

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

נניח שליישום המסחר האלקטרוני שלך יש שלושה מיקרו-שירותים נפרדים:

1. שירות משתמש (מנהל פרופילים)
2. שירות מוצר (מנהל קטלוג)
3. שירות הזמנות (מנהל את התשלום)

ללא שער API, אפליקציית הלקוח צריכה לשלוח בקשות נפרדות ישירות לכתובת האישית של כל שירות (IP או URL):

גישת חיבור ישיר זו יוצרת מספר כאבי ראש גדולים:

• יותר מדי נקודות קצה: אפליקציית הלקוח חייבת לזכור שלוש כתובות URL נפרדות. אם אתה מפצל שירות או משנה את כתובתו, עליך לעדכן את יישום הלקוח.
• סיוט אבטחה: כל שירות מיקרו חייב להטמיע בנפרד אימות (בדיקת אסימוני כניסה), אישורי SSL וכללי חומת אש.
• תקרת רשת: ייתכן שהלקוח יצטרך לבצע שלוש בקשות רשת נפרדות ברשתות סלולריות איטיות רק כדי לטעון דף בודד (לדוגמה, אחזור פרופיל, אחזור פרטי מוצר ואחזור היסטוריית הזמנות).
• הבדלי פרוטוקול: ייתכן שאפליקציית הלקוח שלך תעדיף להשתמש בפרוטוקולי אינטרנט סטנדרטיים כמו HTTP/JSON, אבל השירותים הפנימיים שלך עשויים לתקשר מהר יותר באמצעות פרוטוקולים מיוחדים כמו gRPC או AMQP.

הפתרון: דפוס שער ה-API

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

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

אחריות עיקרית של שער API

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

1. ניתוב: השער לוקח כתובת URL נכנסת (כמו /api/v1/orders) וממפה אותה לכתובת השירות הפנימית הנכונה.
2. אימות והרשאה: השער מאמת אסימוני אבטחה (כמו JWTs) בדלת הכניסה. אם הבקשה לא חוקית, היא נדחית באופן מיידי, וחוסכת את שירותי המיקרו שלך מבזבוז מחזורי CPU על בקשות לא מאומתות.
3. הגבלת תעריפים: היא מונעת מבוטים זדוניים או מלקוחות באגי לשלוח דואר זבל למערכת שלך על ידי הגבלת מספר הבקשות שמשתמש יכול לבצע בדקה.
4. איזון עומסים: השער יכול לחלק תעבורה נכנסת באופן שווה על פני מספר מופעים של מיקרו-שירות כדי למנוע עומס יתר של שרת בודד.
5. תרגום פרוטוקול: זה יכול לתרגם בקשות JSON הפונות למשתמש להודעות gRPC פנימיות בעלות ביצועים גבוהים, מה שמאפשר לשירותים לדבר זה עם זה בשפות המועדפות עליהם.

יישום פשוט: דוגמה לקוד

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

1. ניתוב הצהרתי (Spring Cloud Gateway YAML)

במערכות Java ארגוניות, לעתים קרובות אתה מגדיר ניתוב באמצעות קובץ תצורה פשוט. השער מעביר באופן אוטומטי בקשות על סמך הכללים הבאים:

spring:
  cloud:
    gateway:
      routes:
        - id: user_service_route
          uri: http://internal-user-service:8081
          predicates:
            - Path=/api/users/**
        - id: product_service_route
          uri: http://internal-product-service:8082
          predicates:
            - Path=/api/products/**

2. ניתוב פרוגרמטי (Mockup Node.js Gateway)

אם אתה רוצה לבנות שער API קל משקל ב-Javascript באמצעות Express, זה נראה כך:

const express = require('express');
const { createProxyMiddleware } = require('http-proxy-middleware');
const app = express();
const PORT = 3000;

// 1. Simple Security/Authentication Check at the door
const authenticate = (req, res, next) => {
    const token = req.headers['authorization'];
    if (token === 'secret-handshake-token') {
        next(); // Token is valid, proceed
    } else {
        res.status(401).json({ error: 'Unauthorized Access!' });
    }
};

// Apply auth check to all incoming gateway requests
app.use(authenticate);

// 2. Route requests to correct internal microservices
app.use('/api/users', createProxyMiddleware({ target: 'http://localhost:8081', changeOrigin: true }));
app.use('/api/products', createProxyMiddleware({ target: 'http://localhost:8082', changeOrigin: true }));
app.use('/api/orders', createProxyMiddleware({ target: 'http://localhost:8083', changeOrigin: true }));

app.listen(PORT, () => {
    console.log(`API Gateway running smoothly on port ${PORT}`);
});

יתרונות וחסרונות של דפוס שער API

כמו כל החלטה ארכיטקטונית, לשימוש ב-API Gateway יש פשרות:

מסקנה

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

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

גלה עוד פיתוח תוכנה ותובנות הנדסיות עורפיות בבלוג Ghaznix →