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

שיטה מומלצת

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

קריאה נוספת