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