يتم الآن عرض مستندات Apigee Edge.
انتقِل إلى مستندات
Apigee X. المعلومات
في Apigee Edge، يعالج جهاز التوجيه جميع الزيارات الواردة من واجهة برمجة التطبيقات. وهذا يعني أنّه سيتم التعامل مع جميع طلبات HTTP وHTTPS إلى خادم وكيل Edge API أولاً من خلال جهاز Edge Router. لذلك، يجب توجيه طلب الخادم الوكيل لواجهة برمجة التطبيقات إلى عنوان IP وفتح المنفذ على جهاز التوجيه.
يتيح لك المضيف الافتراضي استضافة عدة أسماء نطاقات على خادم واحد أو مجموعة من الخوادم. بالنسبة إلى Edge، تتوافق الخوادم مع أجهزة توجيه Edge. من خلال تحديد المضيفين الافتراضيين على جهاز توجيه، يمكنك التعامل مع الطلبات الواردة إلى نطاقات متعددة.
يحدد المضيف الظاهري على Edge بروتوكولاً (HTTP أو HTTPS)، إلى جانب منفذ جهاز التوجيه واسم مستعار للمضيف. يكون الاسم المستعار للمضيف عادةً اسم نطاق نظام أسماء نطاقات (DNS) يتم تعيينه على عنوان IP لجهاز التوجيه.
على سبيل المثال، تعرض الصورة التالية جهاز توجيه مع تعريفين للمضيف الافتراضي:
في هذا المثال، يوجد تعريفان للمضيف الظاهري. يتعامل أحدهما مع طلبات HTTPS على النطاق domainName1، في حين يعالج الآخر طلبات HTTP في domainName2.
في الطلب المُرسَل إلى خادم وكيل لواجهة برمجة التطبيقات، يقارن جهاز التوجيه عنوان "المضيف" ورقم المنفذ للطلب الوارد بقائمة الأسماء المستعارة للمضيفين التي تحدّدها جميع المضيفات الافتراضية لتحديد المضيف الظاهري الذي يعالج الطلب.
في ما يلي نموذج تهيئة للمضيفات الظاهرية:
مضادة للأنماط
إنّ تحديد عدة مضيفات افتراضية باستخدام الاسم المستعار للمضيف ورقم المنفذ نفسه في البيئات نفسها أو المختلفة بالمؤسسة أو على مستوى المؤسسات سيؤدي إلى حدوث التباس أثناء توجيه طلبات واجهة برمجة التطبيقات وقد يتسبب في حدوث أخطاء أو سلوك غير متوقّع.
لنستخدم مثالاً لشرح الآثار المترتبة على توفُّر عدة مضيفات افتراضية تحمل الاسم المستعار نفسه للمضيف.
بالنظر إلى وجود مضيفين افتراضيين sandbox and secure تم تحديدهما باستخدام الاسم المستعار نفسه للمضيف، أي api.company.abc.com في بيئة:
باستخدام الإعداد أعلاه، قد يتوفّر سيناريوهان كما هو موضّح في الأقسام التالية.
السيناريو 1 : تم إعداد الخادم الوكيل لواجهة برمجة التطبيقات لقبول الطلبات الموجهة إلى أحد المضيفين الافتراضيين فقط في وضع الحماية
<ProxyEndpoint name="default">
...
<HTTPProxyConnection>
<BasePath>/demo</BasePath>
<VirtualHost>sandbox</VirtualHost>
</HTTPProxyConnection>
...
</ProxyEndpoint>
في هذا السيناريو، عندما تجري تطبيقات العميل الاتصالات إلى خادم وكيل محدد لواجهة برمجة التطبيقات باستخدام
الاسم المستعار للمضيف api.company.abc.com، ستظهر أخطاء 404 بشكل متقطع مع الرسالة:
Unable to identify proxy for host: secure
ويرجع ذلك إلى أنّ جهاز التوجيه يرسل الطلبات إلى كل من المضيفين الافتراضيين sandbox وsecure. عند توجيه الطلبات إلى المضيف الافتراضي sandbox، ستتلقّى تطبيقات العميل استجابة ناجحة. ومع ذلك، عند توجيه الطلبات إلى المضيف الافتراضي secure، سيظهر الخطأ 404 لتطبيقات العميل لأنّه لم يتم إعداد الخادم الوكيل لواجهة برمجة التطبيقات لقبول الطلبات على المضيف الافتراضي secure.
السيناريو 2 : تم إعداد الوكيل لواجهة برمجة التطبيقات لقبول الطلبات الموجهة إلى كل من وضع الحماية للمضيفات الظاهرية والآمنة
<ProxyEndpoint name="default">
...
<HTTPProxyConnection>
<BasePath>/demo</BasePath>
<VirtualHost>sandbox</VirtualHost>
<VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>
...
</ProxyEndpoint>
وفقًا لهذا السيناريو، عندما تُجري تطبيقات العميل طلبات إلى خادم وكيل محدد لواجهة برمجة التطبيقات باستخدام
الاسم المستعار للمضيف api.company.abc.com، ستحصل هذه التطبيقات على استجابة صالحة استنادًا إلى منطق الخادم الوكيل.
ومع ذلك، يؤدي ذلك إلى تخزين بيانات غير صحيحة في "إحصاءات Google" لأنّه يتم توجيه طلبات واجهة برمجة التطبيقات إلى المضيفين الافتراضيين كليهما، في حين كانت الطلبات الفعلية تهدف إلى إرسالها إلى مضيف افتراضي واحد فقط.
وقد يؤثر ذلك أيضًا على معلومات التسجيل وأي بيانات أخرى تستند إلى المضيفين الظاهرين.
التأثير
- أخطاء 404 لأنّه قد يتم توجيه طلبات واجهة برمجة التطبيقات إلى مضيف افتراضي ربما لم يتم ضبط الخادم الوكيل لواجهة برمجة التطبيقات عليه لقبول الطلبات
- بيانات "إحصاءات Google" غير صحيحة لأنّ طلبات البيانات من واجهة برمجة التطبيقات يتم توجيهها إلى جميع المضيفين الافتراضيين الذين لديهم الاسم المستعار نفسه للمضيف في حين لم يتم تقديم الطلبات إلا لمضيف افتراضي محدّد.
أفضل الممارسات
- لا تحدد مضيفات افتراضية متعددة باستخدام الاسم المستعار للمضيف ورقم المنفذ نفسهما في البيئة نفسها أو بيئات مختلفة في مؤسسة.
إذا لزم الأمر تحديد عدة مضيفات افتراضية، استخدِم أسماء مضيفين مستعارة مختلفة في كل مضيف افتراضي كما هو موضح أدناه:
