אנטי-תבנית: הפעלת Proxy בתוך Proxy באמצעות קוד מותאם אישית או כיעד

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

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

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

תבנית אנטי

הפעלת פרוקסי של API אחד מתוך פרוקסי אחר באמצעות HTTPTargetConnection בנקודת הקצה של היעד או באמצעות קוד JavaScript מותאם אישית מובילה לניתוב נוסף ברשת.

הפעלת proxy 2 מ-proxy 1 באמצעות HTTPTargetConnection

בדוגמת הקוד הבאה, קוד ה-Proxy מספר 1 מפעיל את קוד ה-Proxy מספר 2 באמצעות HTTPTargetConnection:

<!-- /antipatterns/examples/2-1.xml -->
<HTTPTargetConnection>
  <URL>https://api-test.example.com/proxy2</URL>
</HTTPTargetConnection>

הפעלת proxy 2 מ-proxy 1 מקוד JavaScript

בדוגמת הקוד הבאה מופעל פרוקסי 2 מפרוקסי 1 באמצעות JavaScript:

<!-- /antipatterns/examples/2-2.xml -->
var response = httpClient.send('https://api-test.example.com/proxy2);
response.waitForComplete();

תהליך קוד

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

‫1) הלקוח שולח בקשה ל-Proxy 1, ‏ 2) הבקשה מ-Proxy 1 ל-Proxy 2 גורמת לניתוב ברשת,
            ‫3) הבקשה מ-Proxy 2 ליעד.
איור 1: זרימת קוד

כפי שמוצג בתרשים, בקשה עוברת דרך כמה רכיבים מבוזרים, כולל הנתב ומעבד ההודעות.

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

השפעה

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

שיטה מומלצת

  • משתמשים בתכונה proxy chaining כדי להפעיל שרת proxy של API אחד מתוך שרת proxy אחר. שרשור שרתי Proxy יעיל יותר כי הוא משתמש בחיבור מקומי כדי להפנות לנקודת הקצה של היעד (שרת Proxy אחר של API).

    בדוגמת הקוד מוצג שרשור של שרתי proxy באמצעות LocalTargetConnection בהגדרת נקודת הקצה:

    <!-- /antipatterns/examples/2-3.xml -->
    <LocalTargetConnection>
      <APIProxy>proxy2</APIProxy>
      <ProxyEndpoint>default</ProxyEndpoint>
    </LocalTargetConnection>

    שרת ה-Proxy של ה-API שהופעל מורץ באותו מעבד הודעות. כתוצאה מכך, הוא לא עובר דרך הרשת, כמו שמוצג באיור הבא:

    ‫1) הלקוח שולח בקשה ל-Proxy 1, ‏ 2) בקשה מ-Proxy 1 ל-Proxy 2 נוצרת באמצעות שיחה פסאודו-מקומית, ‏ 3) בקשה מ-Proxy 2 ליעד.
    איור 2: זרימת קוד עם שרשור של שרתי proxy

קריאה נוספת