אנטי-דפוס: שימוש במדיניות Service Callout כדי להפעיל שירות קצה עורפי ב-API Proxy ללא יעד

הדף הזה רלוונטי ל-Apigee ול-Apigee Hybrid.

לעיון במסמכי התיעוד של Apigee Edge

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

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

תבנית אנטי

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

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

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

<RouteRule name="noroute"/>

שרת proxy שמשתמש בנתיב null הוא שרת 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 לא יכול לספק מידע ניתוחי על התנהגות השירות החיצוני (כמו זמן עיבוד או שיעורי שגיאות), ולכן קשה להעריך את הביצועים של השירות החיצוני.

השפעה

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

שיטה מומלצת

אם שרת proxy ל-API מקיים אינטראקציה רק עם שירות חיצוני אחד, ה-proxy צריך לפעול לפי תבנית העיצוב הבסיסית, שבה שירות הקצה העורפי מוגדר כנקודת היעד של ה-proxy ל-API. שרת proxy ללא כללי ניתוב לנקודת קצה של יעד לא אמור להפעיל שירות לקצה העורפי באמצעות מדיניות 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>

אפשר להשתמש ב-Service callouts כדי לתמוך בתרחישי mashup, שבהם רוצים להפעיל שירותים חיצוניים לפני או אחרי הפעלת נקודת הקצה של היעד. הערות לגבי שירותים לא נועדו להחליף הפעלה של נקודת קצה של יעד.

קריאה נוספת