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