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

أنت الآن بصدد الاطّلاع على مستندات Apigee Edge.
انتقِل إلى مستندات Apigee X. info

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

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

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

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

إعدادات TargetServer

يؤدي إعداد TargetServer إلى فصل عناوين URL المحدّدة لنقاط النهاية عن إعدادات TargetEndpoint أو في سياسات Service Callout. يتم الرجوع إلى TargetServer باستخدام اسم بدلاً من عنوان URL في TargetEndpoint. سيتضمّن إعداد TargetServer اسم مضيف خدمة الخلفية ورقم المنفذ وتفاصيل أخرى.

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

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

يتيح لك TargetServer إعدادات مختلفة لكل بيئة. يمكن ضبط سياسة TargetEndpoint/Service Callout باستخدام خادم TargetServer واحد أو أكثر باستخدام 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 لسياسة TargetEndpoint أو Service Callout مع ضبط 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 إلى التناوب.

إذا تم استخدام الإعداد نفسه في سياسة Service Callout، سيتم عرض الخطأ 500 في طلبات واجهة برمجة التطبيقات بعد تعذُّر إرسال الطلبات إلى TargetServer "target1" 5 مرات.

التأثير

يؤدي استخدام TargetServer واحد في إعداد LoadBalancer لسياسة TargetEndpoint أو Service Callout مع ضبط MaxFailures على قيمة غير صفرية إلى ما يلي:

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

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

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 يحاول دائمًا الاتصال بالهدف لكل طلب ولا يزيل خادم الهدف من التناوب أبدًا.

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

• موازنة الحمل على مستوى خوادم الخلفية
• كيفية استخدام الخوادم المستهدَفة في خوادم API الوكيلة