אתם צופים במסמכי התיעוד של Apigee Edge.
כדאי לעיין במסמכי התיעוד של Apigee X. מידע
כדי לשמור על הביצועים והזמינות של מגוון רחב של אפליקציות לקוח, חשוב לשמור על תנועת האפליקציות במסגרת מגבלות הקיבולת של ממשקי ה-API ושירותי הקצה העורפי. חשוב גם לוודא שהאפליקציות לא צורכות יותר משאבים מהמותר.
ב-Apigee Edge יש שני מנגנונים שמאפשרים לכם לבצע אופטימיזציה של ניהול התנועה כדי לצמצם את זמן האחזור של האפליקציות, תוך שמירה על תקינות שירותי ה-Backend. כל סוג מדיניות מתייחס להיבט שונה של ניהול התנועה. במקרים מסוימים, יכול להיות שתשתמשו בשני סוגי המדיניות בשרת proxy יחיד של API.
כדאי לצפות בסרטון הזה כדי לקבל מבוא למדיניות בנושא ניהול תנועה ב-API.
SpikeArrest
המדיניות הזו מאפשרת להחלקת עליות פתאומיות בנפח התנועה על ידי חלוקת מגבלה שאתם מגדירים למרווחי זמן קטנים יותר. לדוגמה, אם מגדירים מגבלה של 100 הודעות לשנייה, מדיניות SpikeArrest אוכפת מגבלה של בקשה אחת בערך כל 10 אלפיות השנייה (1,000 חלקי 100). אם מגדירים מגבלה של 30 הודעות לדקה, המערכת מחליקה את המגבלה לבקשה אחת בערך כל 2 שניות (60 חלקי 30). ההגבלה של SpikeArrest צריכה להיות קרובה לקיבולת שחושבה לשירות לקצה העורפי או ל-proxy ל-API עצמו. כדאי להגדיר את המגבלה גם למרווחי זמן קצרים יותר, כמו שניות או דקות. המדיניות הזו נועדה למנוע פרצי תנועה פתאומיים שנגרמים על ידי תוקפים זדוניים שמנסים לשבש שירות באמצעות התקפת מניעת שירות (DoS), או על ידי אפליקציות לקוח עם באגים.
מכסה
המדיניות הזו אוכפת מגבלות על צריכת משאבים באפליקציות לקוח, באמצעות 'מונה' מבוזר שמסכם את הבקשות הנכנסות. המונה יכול לספור קריאות ל-API לכל ישות שניתן לזהות, כולל אפליקציות, מפתחים, מפתחות API, אסימוני גישה וכו'. בדרך כלל, מפתחות API משמשים לזיהוי אפליקציות לקוח. המדיניות הזו דורשת הרבה משאבי מחשוב, ולכן בממשקי API עם תנועה גבוהה, מומלץ להגדיר אותה למרווחי זמן ארוכים יותר, כמו יום או חודש. המדיניות הזו מיועדת לאכיפה של חוזים עסקיים או הסכמי רמת שירות (SLA) עם מפתחים ושותפים, ולא לניהול תנועה תפעולי.