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