אתם צופים במסמכי התיעוד של 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 ולהפחית את העומס על שרת בק-אנד.
- לפתור את הבעיה הבסיסית בשרתי הקצה העורפי האיטיים.