מה זה API Gateway¶

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

התפקיד הבסיסי - נקודת כניסה אחת¶

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

לקוח --> API Gateway --> שירות משתמשים
                      --> שירות תשלומים
                      --> שירות התראות

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

מה עוד ה-Gateway עושה מעבר לניתוב¶

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

אימות והרשאה. בדיקת טוקן, אימות זהות המשתמש, ואכיפת הרשאות - קורים פעם אחת בשער, לא בכל שירות בנפרד. זה חוסך שכפול קוד אבטחה קריטי בעשרה מקומות שונים.
הגבלת קצב (rate limiting). מניעת מצב שבו לקוח אחד מציף את המערכת בבקשות, נאכפת במקום מרכזי אחד.
איחוד תשובות (aggregation). לפעמים מסך אחד באפליקציה צריך מידע מכמה שירותים שונים. ה-Gateway יכול לקרוא לכולם במקביל ולהחזיר תשובה מאוחדת אחת, במקום שהלקוח יבצע חמש קריאות נפרדות.
תרגום פרוטוקולים. שירותים פנימיים יכולים לדבר gRPC ביניהם, בזמן שה-Gateway חושף כלפי חוץ REST רגיל שקל יותר לצרוך.
לוגים ומטריקות מרכזיים. נקודה אחת שרואה את כל התעבורה הנכנסת למערכת היא מקום נוח מאוד לאיסוף נתוני ניטור.

ההבדל מ-load balancer¶

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

החיסרון שכדאי להכיר - נקודת כשל יחידה¶

כמו כל רכיב מרכזי, ה-API Gateway יכול להפוך לצוואר בקבוק ואפילו לנקודת כשל יחידה (single point of failure) - אם הוא נופל, כל המערכת מנותקת מהעולם, גם אם כל השירותים הפנימיים תקינים לגמרי. בגלל זה, ב-production אמיתי מריצים כמה עותקים של ה-Gateway מאחורי load balancer משלו, בדיוק כמו כל שירות קריטי אחר, ולא סומכים על עותק בודד.

מתי בכלל צריך את זה¶

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

לסיכום¶

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

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

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