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