אנטי-דפוס: שימוש במדיניות בנושא יתרונות מרכזיים של שירות כדי להפעיל שירות לקצה העורפי בשרת proxy ללא יעד של API

מוצג המסמך של Apigee Edge.
עוברים אל מסמכי תיעוד של Apigee X. מידע

שרת proxy ל-API הוא ממשק חזית מנוהל לשירותים לקצה העורפי. הגדרה בסיסית של שרת proxy ל-API מורכבת ProxyEndpoint (שמגדירות את כתובת ה-URL של שרת ה-proxy ל-API) TargetEndpoint (הגדרת כתובת ה-URL של השירות לקצה העורפי).

Apigee Edge מציעה הרבה גמישות לפיתוח התנהגות מתוחכמת בנוסף לדפוס הזה. לדוגמה, אפשר להוסיף כללי מדיניות כדי לקבוע את האופן שבו ה-API מעבד בקשת לקוח לפני השליחה לשירות לקצה העורפי, או לבצע שינויים בתגובה שהתקבלה מהשירות לקצה העורפי לפני להעביר אותו ללקוח. ניתן להפעיל שירותים אחרים באמצעות מדיניות יתרונות מרכזיים של שירות, להוסיף התנהגות מותאמת אישית על ידי הוספת קוד JavaScript, ואפילו ליצור שרת proxy ל-API שלא מפעיל שירות לקצה העורפי.

נגד דוגמת עיצוב

שימוש בנכסי יתרונות מרכזיים של שירות כדי להפעיל שירות לקצה העורפי בשרת proxy ל-API ללא מסלולים לנקודת קצה (endpoint) יעד מעשית מבחינה טכנית, אבל באופן כזה גורמת לאובדן הנתונים של ניתוח הנתונים לגבי הביצועים של השירות החיצוני.

שרת proxy ל-API שלא מכיל מסלולי יעד יכול להיות שימושי במקרים שבהם לא צריך לבצע העברות. הודעת הבקשה לנקודת הקצה. במקום זאת, נקודת הקצה ProxyEndpoint בעיבוד. לדוגמה, ProxyEndpoint יכול לאחזר נתונים מחיפוש אל מאחסנים מפתחות/ערך ומחזירים את התגובה בלי להפעיל שירות לקצה העורפי.

אפשר להגדיר ניתוב null. בשרת proxy ל-API, כפי שמוצג כאן: 

<RouteRule name="noroute"/>

שרת proxy שמשתמש בנתיב אפס מוגדר כ'ללא יעד' כי הוא לא מפעיל שירות יעד לקצה העורפי.

מבחינה טכנית אפשר להוסיף הסבר על שירות ללא שרת proxy כדי להפעיל שירות חיצוני, כמו בדוגמה הבאה: 

<!-- /antipatterns/examples/service-callout-no-target-1.xml -->
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ProxyEndpoint name="default">
    <Description/>
    <FaultRules/>
    <PreFlow name="PreFlow">
        <Request>
            <Step>
                <Name>ServiceCallout-InvokeBackend</Name>
            </Step>
        </Request>
        <Response/>
    </PreFlow>
    <PostFlow name="PostFlow">
        <Request/>
        <Response/>
    </PostFlow>
    <Flows/>
    <HTTPProxyConnection>
        <BasePath>/no-target-proxy</BasePath>
        <Properties/>
        <VirtualHost>secure</VirtualHost>
    </HTTPProxyConnection>
    <RouteRule name="noroute"/>
</ProxyEndpoint>

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

השפעה

  • מידע לניתוח נתונים על האינטראקציה עם השירות החיצוני ( קודי שגיאה, זמן תגובה, יעד ביצועים וכו') לא זמין
  • כל לוגיקה ספציפית שנדרשת לפני או אחרי הפעלת ההסבר על השירות נכללת בתור חלק מהלוגיקה הכוללת של שרת ה-proxy, שמקשה על הבנה ושימוש חוזר.

שיטה מומלצת

אם שרת proxy ל-API מקיים אינטראקציה עם שירות חיצוני אחד בלבד, שרת ה-proxy צריך לפעול על פי ההנחיות הבסיסיות דפוס תכנון, שבו השירות לקצה העורפי מוגדר כנקודת הקצה כיעד של שרת ה-proxy ל-API. שרת proxy ללא כללי ניתוב לנקודת קצה (endpoint) מסוג יעד, אסור להפעיל שירות לקצה עורפי באמצעות המדיניות ServiceCallout.

התצורה הבאה של שרת ה-proxy מיישמת את אותה התנהגות כמו בדוגמה שלמעלה, אך היא פועלת בצורה הטובה ביותר שיטות: 

<!-- /antipatterns/examples/service-callout-no-target-2.xml -->
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ProxyEndpoint name="default">
    <Description/>
    <FaultRules/>
    <PreFlow name="PreFlow">
        <Request/>
        <Response/>
    </PreFlow>
    <PostFlow name="PostFlow">
        <Request/>
        <Response/>
    </PostFlow>
    <Flows/>
    <HTTPProxyConnection>
        <BasePath>/simple-proxy-with-route-to-backend</BasePath>
        <Properties/>
        <VirtualHost>secure</VirtualHost>
    </HTTPProxyConnection>
    <RouteRule name="default">
        <TargetEndpoint>default</TargetEndpoint>
    </RouteRule>
</ProxyEndpoint>

שימוש בתוספי יתרונות מרכזיים של שירות כדי לתמוך בתרחישים של mashup, שבהם רוצים להפעיל שירותים חיצוניים לפני כן או אחרי הפעלה של נקודת הקצה של היעד. נכסי היתרונות המרכזיים לא אמורים להחליף את נקודת הקצה (endpoint) של היעד הפעלה.

קריאה נוספת