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