19.03.01 – נתוני הגרסה של Apigee Edge ל-Public Cloud

איזון עומסים – יותר שליטה בהסרת שרתים שנכשלו

כשמגדירים את מאזן העומסים לשרת proxy ל-API, אפשר לקבוע כמה תגובות כשלים מתרחשים לפני הסרת שרת מהרוטציה של איזון העומסים. התשובה נכשלה המשמעות היא ש-Apigee לא מקבלת תגובה משרת יעד. במקרה כזה, כשל את המונה של מונה אחד. כש-Apigee מקבלת תגובה מיעד, גם אם היא שגיאת HTTP (למשל 500) שנספרת כתגובה משרת היעד. ומונה הכשלים יאופס. כדי להבטיח שתגובות HTTP לא תקינות (כמו 500) הגדלה של מונה הכשלים כדי להוציא שרת לא תקין מסבב איזון העומסים באופן הבא: בהקדם האפשרי, אפשר להוסיף רכיב <ServerUnhealthyResponse> חדש עם <ResponseCode> רכיבי צאצא להגדרות של מאזן העומסים. דפדפן Edge גם יספור תגובות עם הקודים האלה ככשלים.

<HTTPTargetConnection>
  <LoadBalancer>
    <Algorithm>RoundRobin</Algorithm>
    <Server name="target1" />
    <Server name="target2" />
    <ServerUnhealthyResponse>
        <ResponseCode>500</ResponseCode>
        <ResponseCode>502</ResponseCode>
        <ResponseCode>503</ResponseCode>
    </ServerUnhealthyResponse>
    <MaxFailures>5</MaxFailures>
  </LoadBalancer>
</HTTPTargetConnection>
  
  

שיפורים במדיניות בקרת הגישה

מדיניות AccessControl קובעת אילו כתובות IP יכולות לשלוח קריאות לשרת proxy ל-API. רכיב חדש במדיניות הזו נותן למפתחי API יותר שליטה בזיהוי כתובת ה-IP כתובות לבדיקה.

<IgnoreTrueClientIPHeader>: אופציונלי (ברירת המחדל היא False). כשהמדיניות מוגדרת כ-True, המדיניות מתעלמת מהכותרת True-Client-IP ו הערכה של כתובות IP בכותרת X-Forwarded-For, אחרי התנהגות ההערכה X-Forwarded-For שהגדרת.

<AccessControl async="false" continueOnError="false"
    enabled="true" name="Access-Control-1">
    <DisplayName>Access Control-1</DisplayName>
    <IgnoreTrueClientIPHeader>true</IgnoreTrueClientIPHeader>
    ...
</AccessControl>

פרטים נוספים זמינים במאמר הפוסט הזה לקהילה.

שני רכיבים חדשים זמינים במדיניות IncreaseFault ליצירת FaultRules נקייה ועוצמתית יותר.

• ShortFaultReason הוא ערך בוליאני. אם המדיניות מוגדרת כ-True, שם המדיניות יתווסף למשתנה fault.reason.
• הפונקציה AssignVariable, שזמינה ב-FultResponse, מאפשרת להקצות את תגובת השגיאה למשתנה שישמש בכללי מדיניות אחרים בתהליך ה-proxy ל-API.

אנחנו אוכפים עכשיו את המגבלות של יעדים מתארחים. בקטע מגבלות אפשר לקרוא מידע נוסף על המגבלות.

עכשיו תוכלו להשתמש במשתנים של תבניות הודעות כדי להגדיר כתובות IP ומסכות CIDR מדיניות AccessControl. לדוגמה, אם רוצים לאחסן כתובת IP והתממה במפת ערכי מפתח (KVM), אפשר לאחזר את הערכים האלה ממשתנה שאתם מגדירים בתהליך ה-Proxy ל-API. כך ניתן לשנות ערכי IP בקלות רבה יותר בזמן ריצה ללא צורך לשנות את הגדרת המדיניות.

לדוגמה, במקום:

<MatchRule action="DENY">
    <SourceAddress mask="24">198.51.100.1</SourceAddress>
</MatchRule>
     

אפשר להגדיר את המדיניות באופן הבא, בהנחה שהערכים מאוחסנים ב-KVM, ומשתמשים במדיניות KeyValueMapOperations כדי לאחזר את הערכים ולהקצות אותם המשתנים שמוצגים כאן:

<MatchRule action="DENY">
    <SourceAddress mask="{kvm.mask.ref}">{kvm.ip.ref}</SourceAddress>
</MatchRule>
     

יש שני תפקידים ב-API Monitoring: אדמין Monitoring ו-API Monitoring, כפי שמתואר במאמר Access API Monitoring. הנושאים האלה זמינים בדצמבר 2018.

Edge מוסיף עכשיו את הכותרת X-Apigee.Message-Timeout לכל בקשה. הכותרת הזו מיועד לשימוש פנימי על ידי Edge. לא להסתמך על הערכים בכותרות X-Apigee.* בשרתי ה-proxy ל-API כי הכותרות האלה לא מיועדות לשימוש לקוחות, ו-Apigee יכולה להסיר או לשנות אותן בכל שלב.

טיפול בשגיאות מחיקה של מאגר מפתחות כדי שהקריאה ל-API לא תיכשל

x-apigee.edge.execution.sense.action תמיד מוגדר כ-null

במדיניות ResponseCache, NIOTheread מופעל ללא דחייה מ מאגר שרשורים

מספר רב של יצואנים של יומנים בנתבים של Apigee גורמים לשימוש גבוה במעבדים (CPU)

שגיאות 404 לסירוגין בארגונים ספציפיים

תהליך עבודה משותף שנפרס לא פועל בחלק ממעבדי ההודעות

התיקון הזה ייכלל בגרסה הבאה של Edge for Private Cloud.

התיקון הזה ייכלל בגרסה הבאה של Edge לענן פרטי.

התיקון הזה ייכלל בגרסה הבאה של Edge for Private Cloud.