Antipattern: موازنة الحمل من خلال خادم مستهدف واحد تم ضبط قيمة MaxFailures على قيمة غير صفرية

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

تحدد إعدادات TargetEndpoint طريقة اتصال Apigee Edge واجهة برمجة التطبيقات أو خدمة الخلفية. يرسل الطلبات ويتلقى الردود من/إلى خدمة الخلفية. ويمكن أن تكون خدمة الخلفية خادم HTTP/HTTPS أو خادم NodeJS أو هدف مستضاف.

يمكن استدعاء خدمة الخلفية في TargetEndpoint بإحدى الطرق التالية:

• توجيه عنوان URL إلى خادم HTTP أو HTTPS
• ScriptTarget إلى نص برمجي Node.js مستضاف على Edge
• تم نشر HostedTarget على NodeJS في البيئة المستهدفة المستضافة
• إعدادات TargetServer

وبالمثل، يمكن استخدام سياسة وسائل شرح الخدمة لإجراء اتصال بأي خدمة خارجية من مسار الخادم الوكيل لواجهة برمجة التطبيقات. تسمح هذه السياسة بتحديد عناوين URL التي تستهدف HTTP/HTTPS. مباشرةً في السياسة نفسها أو باستخدام إعدادات TargetServer

إعدادات TargetServer

تعمل إعدادات TargetServer على فصل عناوين URL لنقاط النهاية الملموسة عن إعدادات TargetEndpoint أو في سياسات "وسائل شرح الخدمة" إن TargetServer عبارة عن تتم الإشارة إليه باسم بدلاً من عنوان URL في TargetEndpoint. إعدادات TargetServer على اسم المضيف لخدمة الخلفية ورقم المنفذ وتفاصيل أخرى.

وفي ما يلي نموذج لإعداد TargetServer:

<TargetServer name="target1">
  <Host>www.mybackendservice.com</Host>
  <Port>80</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer>

يتيح لك TargetServer الحصول على عمليات ضبط مختلفة لكل بيئة. يمكن ضبط سياسة وسائل شرح TargetEndpoint/Service باستخدام عنصر واحد أو أكثر باسم TargetServers. باستخدام LoadBalancer. يعزز التوافق المُدمَج لموازنة الحمولة مدى توفُّر لواجهات برمجة التطبيقات وتجاوز الأعطال بين مثيلات خادم الخلفية التي تم إعدادها.

وفي ما يلي نموذج لضبط TargetEndpoint باستخدام TargetServers:

<TargetEndpoint name="default">
    <HTTPTargetConnection>>
      <LoadBalancer>
        <Server name="target1"/>
      <Server name="target2"/>
      </LoadBalancer>
    </HTTPTargetConnection>
</TargetEndpoint>

MaxFailures

تحدّد إعدادات MaxFailures الحد الأقصى لعدد الطلبات التي تعذّر تنفيذها. إلى الخادم الهدف الذي يتم بعده وضع علامة على الخادم الهدف بوصفه معطلاً وإزالته من التناوب لجميع الطلبات اللاحقة.

مثال على الإعدادات ذات السمة MaxFailures المحدّدة:

<TargetEndpoint name="default">
    <HTTPTargetConnection>
      <LoadBalancer>
        <Server name="target1"/>
       <Server name="target2"/>
       <MaxFailures>5</MaxFailures>
      </LoadBalancer>
    </HTTPTargetConnection>
</TargetEndpoint>

في المثال أعلاه، إذا تعذّر تنفيذ خمسة طلبات متتالية لـ "target1" ثم "target1" ستتم إزالته من التناوب وسيتم إرسال جميع الطلبات اللاحقة إلى target2 فقط.

نقوش

وجود TargetServer واحد في تهيئة LoadBalancer نقطة النهاية المستهدفة أو سياسة وسيلة شرح الخدمة مع ضبط "MaxFailures" على لا يوصى باستخدام قيمة غير صفرية إذ قد تترتب آثار سلبية.

ضع في الاعتبار نموذج التهيئة التالي الذي يحتوي على TargetServer واحد باسم "target1" عند ضبط MaxFailures على 5 (قيمة غير صفرية):

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <MaxFailures>5</MaxFailures>
      </LoadBalancer>
  </HTTPTargetConnection>

إذا كانت الطلبات إلى TargetServer "target1" إخفاق خمس مرات (الرقم المحدد في MaxFailures)، تتم إزالة TargetServer من التناوب. ونظرًا لعدم وجود TargetServers آخرًا تفشل في الوصول إليه، ستفشل جميع الطلبات اللاحقة إلى الخادم الوكيل لواجهة برمجة التطبيقات الذي يتضمن هذه التهيئة مع خطأ واحد (503 Service Unavailable).

حتى إذا كان TargetServer "target1" يعود إلى حالته الطبيعية ويستطيع من إرسال ردود ناجحة، سيستمر إرسال الطلبات إلى الخادم الوكيل لواجهة برمجة التطبيقات لإرجاع أخطاء 503. وذلك لأن Edge لا يضع TargetServer تلقائيًا حتى بعد تشغيل الهدف وإعادة تشغيله. لمعالجة هذه المشكلة، يجب إعادة نشر خادم وكيل واجهة برمجة التطبيقات لكي يضع Edge إعادة تدوير TargetServer.

في حالة استخدام التهيئة نفسها في سياسة وسيلة شرح الخدمة، فعندئذٍ ستتلقى الطلبات رسالة الخطأ 500 بعد تنفيذ الطلبات إلى TargetServer "target1". فشل 5 مرات.

التأثير

استخدام TargetServer واحدًا في إعداد LoadBalancer لـ قيمة سياسة نقطة النهاية المستهدفة أو سياسة وسيلة شرح الخدمة مع ضبط MaxFailures على أسباب غير صفرية:

• تعذُّر معالجة طلبات واجهة برمجة التطبيقات مع حدوث أخطاء 503/500 بشكل مستمر (بعد تعذُّر الطلبات لعدد مرات تجاوز الحد الأقصى لعدد مرات التعذُّر) إلى أن تتم إعادة نشر الخادم الوكيل لواجهة برمجة التطبيقات
• انقطاع الخدمة لمدة أطول لأنّه معقّد وقد يستغرق وقتًا أطول لتشخيص سبب المشكلة (بدون معرفة مسبقة بهذا النمط المضاد).

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

1. يجب ضبط أكثر من TargetServer واحدًا في إعدادات LoadBalancer لزيادة مدى التوفّر.

2. تحديد "جهاز متابعة الصحة" دائمًا في الحالات التالية: MaxFailures يتم تعيينها على قيمة غير صفرية. ستتم إزالة الخادم الهدف من التناوب عندما يصل عدد الإخفاقات إلى الرقم المحدّد في MaxFailures. ويضمن الحصول على HealthMonitor إعادة تدوير TargetServer بمجرد أن يصبح الخادم الهدف متاحًا مرة أخرى، مما يعني توفر فلا حاجة إلى إعادة نشر الخادم الوكيل

   لضمان إجراء الفحص الصحي على رقم المنفذ نفسه الذي تستخدم Edge في الاتصال بالخوادم المستهدفة، وتوصي Apigee بحذف العنصر الفرعي <Port> ضمن <TCPMonitor> ما لم يكن عن منفذ TargetServer. يكون <Port> هو نفسه تلقائيًا منفذ TargetServer.

   نموذج الإعدادات باستخدام HealthMonitor:

   <TargetEndpoint name="default">
     <HTTPTargetConnection>
       <LoadBalancer>
         <Algorithm>RoundRobin</Algorithm>
         <Server name="target1" />
         <Server name="target2" />
         <MaxFailures>5</MaxFailures>
       </LoadBalancer>
       <Path>/test</Path>
       <HealthMonitor>
         <IsEnabled>true</IsEnabled>
         <IntervalInSec>5</IntervalInSec>
         <TCPMonitor>
           <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
         </TCPMonitor>
       </HealthMonitor>
     </HTTPTargetConnection>
   </TargetEndpoint>
   

3. إذا كان هناك بعض القيود مثل TargetServer واحد فقط وما إذا كانت HealthMonitor لم يتم استخدامها، ثم عدم تحديد MaxFailures في إعداد LoadBalancer.

   القيمة التلقائية لـ MaxFailures هي 0. وهذا يعني أن Edge دائمًا الاتصال بالهدف لكل طلب ولا يزيل الخادم الهدف من عملية التناوب أبدًا.

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

• موازنة التحميل في خوادم الخلفية
• كيفية استخدام الخوادم المستهدفة في الخوادم الوكيلة لواجهة برمجة التطبيقات