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

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

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

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

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

הפעלת שרת Proxy 2 מ-Proxy 1 באמצעות HTTPTargetConnection

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

<!-- /antipatterns/examples/2-1.xml -->
<HTTPTargetConnection>
  <URL>http://myorg-test.apigee.net/proxy2</URL>
</HTTPTargetConnection>

הפעלת שרת Proxy 2 מ-Proxy 1 מקוד JavaScript

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

<!-- /antipatterns/examples/2-2.xml -->
var response = httpClient.send('http://myorg-test.apigee.net/proxy2);
response.waitForComplete();

זרימת קוד

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

איור 1: תהליך הזנת קוד

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

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

השפעה

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

שיטה מומלצת

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

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

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

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

    איור 2: זרימת קוד עם שרשור של שרת proxy

קריאה נוספת