מוצג המסמך של Apigee Edge.
עוברים אל
מסמכי תיעוד של Apigee X. מידע
שרת proxy ל-API הוא ממשק לאפליקציות לקוח שמשמשות להתחברות לשירותים לקצה העורפי. ב-Apigee Edge יש כמה דרכים להתחבר לשירותים לקצה העורפי באמצעות שרת proxy ל-API:
- targetEndpoint: כדי להתחבר לכל שירות HTTP או HTTP, NodeJS או יעד מארח.
- מדיניות ServiceCallout כדי להפעיל כל שירות חיצוני לפני ההפעלה של שרת היעד או אחריו ב-TargetEndpoint.
- נוסף קוד מותאם אישית למדיניות JavaScript או למדיניות JavaCallout כדי להתחבר לשירותים לקצה העורפי.
חיבורים קבועים
חיבור קבוע מסוג HTTP, נקראת גם 'שימוש חוזר בחיבור HTTP' או 'שימוש חוזר בחיבור HTTP', הוא קונספט שמאפשר חיבור TCP לשליחה ו מקבלים כמה בקשות HTTP/תגובות, במקום לפתוח חיבור חדש לכל צמד של בקשה/תגובה.
Apigee Edge משתמשת בחיבור קבוע לתקשורת עם שירותים לקצה העורפי. החיבור נשאר פעיל למשך 60 שניות כברירת מחדל. כלומר, אם חיבור לא פעיל במאגר החיבורים יותר מ-60 שניות, החיבור נסגר.
אפשר להגדיר את פרק הזמן הקצוב לתפוגה של שמירה במצב פעיל דרך נכס בשם keepalive.timeout.millis
,
שצוינו בתצורה של TargetEndpoint של שרת ה-proxy ל-API. לדוגמה, כדי להמשיך
ניתן להגדיר תקופה ל-30 שניות לשירות קצה עורפי ספציפי בנקודת הקצה (TargetEndpoint).
בדוגמה הבאה, הערך keepalive.timeout.millis
מוגדר ל-30 שניות בנקודת הקצה (TargetEndpoint)
תצורה:
<!-- /antipatterns/examples/disable-persistent-connections-1.xml --> <TargetEndpoint name="default"> <HTTPTargetConnection> <URL>http://mocktarget.apigee.net</URL> <Properties> <Property name="keepalive.timeout.millis">30000</Property> </Properties> </HTTPTargetConnection>Disable HTTP persistent (Reusable keep-alive) connections </TargetEndpoint>
בדוגמה שלמעלה, keepalive.timeout.millis
שולט/ת בהתנהגות של שמירה על חיי המשתמש
שירות לקצה עורפי ספציפי בשרת proxy ל-API. יש גם נכס ששולט בהתנהגות החיה
לכל השירותים לקצה העורפי בכל שרתי ה-proxy. HTTPTransport.keepalive.timeout.millis
ניתן להגדרה ברכיב מעבד ההודעות. ערך ברירת המחדל של הנכס הזה הוא 60
שניות. ביצוע שינויים בנכס הזה ישפיע על התנהגות החיבור הפעיל בין
Apigee Edge וכל השירותים לקצה העורפי בכל שרתי ה-proxy ל-API.
נגד דוגמת עיצוב
השבתת חיבורים קבועים (המשך פעילות) באמצעות הגדרת הנכס keepalive.timeout.millis
ל-0 בתצורה של TargetEndpoint של שרת Proxy ספציפי ל-API, או בהגדרה של
לא מומלץ להשתמש במספר HTTPTransport.keepalive.timeout.millis
עד 0 במעבדי הודעות בתור
תהיה לכך השפעה על הביצועים.
בדוגמה הבאה, ההגדרה של TargetEndpoint משביתה חיבורים קבועים (משאירים חיים)
לשירות לקצה עורפי ספציפי על ידי הגדרה של keepalive.timeout.millis
ל-0:
<!-- /antipatterns/examples/disable-persistent-connections-2.xml --> <TargetEndpoint name="default"> <HTTPTargetConnection> <URL>http://mocktarget.apigee.net</URL> <Properties> <Property name="keepalive.timeout.millis">0</Property> </Properties> </HTTPTargetConnection> </TargetEndpoint>
אם האפשרות להשאיר חיבורים פעילים מושבתת בשירות אחד או יותר לקצה העורפי, Edge צריך לפתוח חיבור חדש לכל בקשה חדשה לשירותי היעד העורפי. אם הקצה העורפי הוא HTTP, Edge גם יבצע לחיצת יד של SSL עבור כל בקשה חדשה, ויוסיף זמן האחזור של בקשות API.
השפעה
- מאריך את זמן התגובה הכולל של בקשות API מכיוון ש-Apigee Edge חייב לפתוח חיבור חדש לבצע לחיצת יד של SSL עבור כל בקשה חדשה.
- יכול להיות שהחיבורים יתנתקו בגלל תנאי תנועה גבוהים, כי שחרור החיבורים עשוי להימשך זמן מה חזרה למערכת.
שיטה מומלצת
- שירותים לקצה העורפי צריכים לפעול בהתאם לחיבור עקבי של HTTP ולטפל בו בהתאם ל-HTTP 1.1 רגילים.
- שירותים לקצה העורפי צריכים להגיב עם כותרת
Connection:keep-alive
, אם הם יכולים כדי לטפל בחיבורים מתמידים (חיים). - שירותים לקצה העורפי צריכים להגיב עם כותרת
Connection:close
אם הם לא יכולים לטפל בחיבורים קבועים.
הטמעת הדפוס הזה תבטיח ש-Apigee Edge יוכל לטפל אוטומטית בנתונים קבועים או לא קבועים חיבור לשירותים לקצה העורפי, בלי שיידרשו שינויים בשרת ה-proxy של ה-API.