הדף הזה רלוונטי ל-Apigee ול-Apigee Hybrid.
לעיון במסמכי התיעוד של Apigee Edge
מערכות בקצה העורפי מריצות את השירותים ששרתי proxy ל-API ניגשים אליהם. במילים אחרות, הם הסיבה הבסיסית לקיומם של ממשקי API ושכבת ה-Proxy לניהול ממשקי API.
כל בקשת API שמנותבת דרך פלטפורמת Apigee עוברת בנתיב טיפוסי לפני שהיא מגיעה לקצה העורפי:
- הבקשה מגיעה מלקוח, שיכול להיות כל דבר מדפדפן ועד אפליקציה.
- הבקשה מתקבלת בשער Apigee.
- היא מעובדת בשער. כחלק מהעיבוד הזה, הבקשה מועברת למספר רכיבים מבוזרים.
- לאחר מכן, השער מעביר את הבקשה אל ה-backend שמגיב לבקשה.
- התגובה מהקצה העורפי עוברת בחזרה בדיוק באותו נתיב הפוך דרך שער Apigee, עד שהיא מגיעה ללקוח.
למעשה, הביצועים של בקשות API שמנותבות דרך Apigee תלויים גם ב-Apigee וגם במערכות העורפיות. בדפוס האנטי הזה נתמקד בהשפעה על בקשות API בגלל מערכות קצה עורפיות עם ביצועים נמוכים.
תבנית אנטי
נניח שיש בעיה בקצה העורפי. אלה האפשרויות:
הקצה העורפי קטן מדי
הבעיה בחשיפת השירותים במערכות קצה עורפיות כאלה באמצעות ממשקי API היא שהגישה אליהם פתוחה למספר רב של משתמשי קצה. מנקודת מבט עסקית, זה אתגר רצוי, אבל צריך לטפל בו.
במקרים רבים, מערכות הבק-אנד לא מוכנות לביקוש הנוסף הזה לשירותים שלהן, ולכן הן קטנות מדי או שלא בוצע בהן אופטימיזציה לתגובה יעילה.
הבעיה עם קצה עורפי 'קטן מדי' היא שאם יש עלייה חדה במספר הבקשות ל-API, המשאבים כמו מעבד (CPU), עומס וזיכרון במערכות העורפיות יהיו בלחץ. בסופו של דבר, בקשות ה-API ייכשלו.
קצה עורפי איטי
הבעיה עם קצה עורפי שלא מותאם בצורה נכונה היא שזמן התגובה שלו לכל בקשה שנשלחת אליו יהיה ארוך מאוד, וכתוצאה מכך יהיו השהיות ארוכות יותר, תום זמן קצוב לתפוגה מוקדם מדי וחוויית לקוח פגומה.
פלטפורמת Apigee מציעה כמה אפשרויות שניתנות להתאמה כדי לעקוף את הבעיה של קצה העורף האיטי ולנהל אותו. אבל יש מגבלות על האפשרויות האלה.
השפעה
- אם ה-backend קטן מדי, עלייה בתעבורת נתונים עלולה לגרום לכך שבקשות ייכשלו.
- במקרה של קצה עורפי איטי, זמן האחזור של הבקשות יתארך.
שיטה מומלצת
- כדאי להשתמש בשמירה במטמון כדי לאחסן את התשובות, לשפר את זמני התגובה של ה-API ולהפחית את העומס על שרת הקצה העורפי.
- לפתור את הבעיה הבסיסית בשרתי הקצה העורפי האיטיים.