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