Antipattern: تحديد عدة مضيفين افتراضيين باستخدام الاسم المستعار للمضيف ورقم المنفذ نفسه

أنت تعرض مستندات Apigee Edge.
انتقل إلى مستندات Apigee X.
معلومات

في Apigee Edge، يتعامل جهاز التوجيه مع جميع الزيارات الواردة من واجهات برمجة التطبيقات. وهذا يعني أن كل بروتوكولات HTTP وHTTPS يتعامل جهاز توجيه Edge أولاً مع الطلبات إلى الخادم الوكيل لواجهة برمجة التطبيقات Edge. لذلك، لا يمكن طلب خادم وكيل لواجهة برمجة التطبيقات يجب توجيهها إلى عنوان IP وفتح المنفذ على جهاز التوجيه.

يتيح لك المضيف الافتراضي استضافة أسماء نطاقات متعددة على خادم واحد أو مجموعة واحدة من الخوادم. بالنسبة إلى Edge، تتوافق الخوادم مع أجهزة توجيه Edge. وبتحديد الأجهزة المضيفة الظاهرية على جهاز توجيه، يمكنك التعامل مع الطلبات إلى نطاقات متعددة.

المضيف الظاهري على Edge يُحدد بروتوكولاً (HTTP أو HTTPS)، إلى جانب منفذ جهاز التوجيه واسم مستعار للمضيف. وعادةً ما يكون الاسم المستعار للمضيف هو اسم نطاق نظام أسماء النطاقات (DNS) الذي يتم ربطه بعنوان IP لجهاز التوجيه.

على سبيل المثال، تُظهر الصورة التالية جهاز توجيه بتعريفين للمضيف الظاهري:

في هذا المثال، يوجد تعريفان للمضيف الظاهري. معالجة واحدة لطلبات HTTPS على domainName1، ي التعامل مع طلبات HTTP على domainName2.

عند إدخال طلب إلى خادم وكيل لواجهة برمجة التطبيقات، يقارن جهاز التوجيه بين رأس المضيف ورقم المنفذ للبيانات الواردة طلب إلى قائمة الأسماء المستعارة للمضيفين التي تحددها جميع المضيفات الظاهرية لتحديد المضيف الظاهري يتولى الطلب.

في ما يلي نموذج إعدادات المضيفات الافتراضية:

نموذج من إعدادات vhost

نقوش

تحديد مضيفين افتراضيين متعددين لهم نفس اسم المضيف المستعار ورقم المنفذ في النطاق نفسه بيئات المؤسسة أو عبر المؤسسات إلى حدوث ارتباك في وقت توجيه طلبات البيانات من واجهة برمجة التطبيقات وقد يتسبب ذلك في حدوث أخطاء أو سلوك غير متوقع.

لنستخدم مثالاً لشرح آثار وجود عدة مضيفات افتراضية بنفس الاسم المستعار للمضيف.

لنفترض أنّ هناك مضيفَين افتراضيَين sandbox and secure محددان بنفس الاسم المستعار للمضيف، أي api.company.abc.com في بيئة:

vhosts بالاسم المستعار نفسه

باستخدام الإعداد أعلاه، يمكن أن يكون هناك حالتان كما هو موضح في الأقسام التالية.

السيناريو 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" أثناء توجيه طلبات البيانات من واجهة برمجة التطبيقات إلى المضيفين الظاهريين معًا، في حين أن الطلبات الفعلية كانت تهدف إلى إرسالها إلى مضيف ظاهري واحد فقط.

ويمكن أن يؤثر هذا أيضًا على معلومات التسجيل وأي بيانات أخرى تستند إلى المضيفات الظاهرية.

التأثير

  1. أخطاء 404، حيث قد يتم توجيه طلبات واجهة برمجة التطبيقات إلى مضيف افتراضي قد لا يتم توجيه الخادم الوكيل لواجهة برمجة التطبيقات إليه مهيأ لقبول الطلبات.
  2. بيانات "إحصاءات Google" غير صحيحة، إذ يتم توجيه طلبات البيانات من واجهة برمجة التطبيقات إلى جميع المضيفات الافتراضية التي تملك نفس الاسم المستعار للمضيف بينما يتم تقديم الطلبات لمضيف ظاهري محدد فقط.

أفضل الممارسات

  • لا تحدد عدة مضيفات افتراضية باستخدام اسم المضيف المستعار نفسه ورقم المنفذ في البيئة نفسها، أو بيئات مختلفة للمؤسسة.
  • وإذا كانت هناك حاجة إلى تحديد عدة مضيفات افتراضية، فاستخدم أسماء مستعارة مختلفة للمضيف في كل من المضيفين الظاهريين كما هو موضح أدناه:

    اثنين من المضيفين

محتوى إضافي للقراءة