موازنة الحمل عبر خوادم الخلفية

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

يساعد Apigee Edge على تحسين مدى توفُّر واجهة برمجة التطبيقات من خلال توفير دعم مضمَّن لتحميل البيانات. تحقيق التوازن وتجاوز الأعطال عبر مثيلات خادم الخلفية المتعددة.

تعمل إعدادات TargetServer على فصل عناوين URL لنقاط النهاية الملموسة عن TargetEndpoint الإعدادات. تتم الإشارة إلى كل TargetServer بالاسم في TargetEndpoint HTTPConnection. بدلاً من تحديد عنوان URL محدد في التكوين، يمكنك تهيئة عنوان أو أكثر من TargetServers المسمّاة كما هو موضح في القسم TargetEndpoint (نقطة النهاية المستهدفة).

يتكون تعريف TargetServer من اسم ومضيف ومنفذ، مع عنصر إضافي الإشارة إلى ما إذا كان TargetServer مُفعَّلاً أو غير مفعَّل.

الفيديوهات

لمعرفة المزيد من المعلومات حول توجيه واجهة برمجة التطبيقات وموازنة التحميل باستخدام الهدف، شاهِد الفيديوهات التالية. الخوادم

نموذج تهيئة TargetServer

تحدد التعليمة البرمجية التالية الخادم الهدف:

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

عناصر إعداد TargetServer

يصف الجدول التالي العناصر المستخدمة لإنشاء وتكوين خادم TargetServer:

إدارة الخوادم المستهدفة باستخدام واجهة المستخدم

إدارة الخوادم الهدف، كما هو موضَّح أدناه.

إدارة الخوادم الهدف باستخدام واجهة برمجة التطبيقات

يمكنك استخدام Edge API لإنشاء الخوادم الهدف وحذفها وتحديثها والحصول عليها وإدراجها. بالنسبة لمزيد من المعلومات، يُرجى الاطّلاع على TargetServers.

استخدِم طلب البيانات التالي من واجهة برمجة التطبيقات لإنشاء خادم هدف:

$ curl -H "Content-Type:text/xml" -X POST -d \
'<TargetServer name="target1">
   <Host>1.mybackendservice.com</Host>
   <Port>80</Port>
   <IsEnabled>true</IsEnabled>
 </TargetServer>' \
-u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers

نموذج الإجابة:

{
  "host" : "1.mybackendservice.com",
  "isEnabled" : true,
  "name" : "target1",
  "port" : 80
}

بعد إنشاء TargetServer الأول، استخدم طلب البيانات التالي من واجهة برمجة التطبيقات لإنشاء TargetServer ثانٍ. من خلال تحديد اثنين من عناصر TargetServers، يمكنك توفير عنوانَي URL يمكن استخدامهما من خلال TargetEndpoint لموازنة التحميل:

$ curl -H "Content-type:text/xml" -X POST -d \
'<TargetServer  name="target2">
  <Host>2.mybackendservice.com</Host>
  <Port>80</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer >' \
-u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers

نموذج الإجابة:

{
  "host" : "2.mybackendservice.com",
  "isEnabled" : true,
  "name" : "target2",
  "port" : 80
}

يمكنك استخدام طلب البيانات التالي من واجهة برمجة التطبيقات لاسترداد قائمة TargetServers في بيئة ما:

$ curl -u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers

نموذج الرد:

[ "target2", "target1" ]

يتوفر الآن نوعان من TargetServers متاحان لاستخدامهما من خلال الخوادم الوكيلة لواجهة برمجة التطبيقات التي تم نشرها في الاختبار. محددة. لتحميل توازن عدد الزيارات عبر TargetServers هذه، يمكنك تهيئة بروتوكول HTTP في نقطة النهاية المستهدفة للخادم الوكيل لواجهة برمجة التطبيقات لاستخدام TargetServers.

هناك حد يبلغ 500 خادم TargetServer لكل بيئة، موثّقة في موضوع الحدود.

تهيئة targetEndpoint لتحميل الرصيد في TargetServers المُسمّى

الآن بعد أن يتوفر لديك اثنان من TargetServers، يمكنك تعديل TargetEndpoint HTTP اتصال للإشارة إلى هذين الخادمين المستهدَفين حسب الاسم:

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

الضبط أعلاه هو أبسط الإعدادات الممكنة لموازنة التحميل. التحميل يدعم جهاز موازنة الحمل ثلاث خوارزميات لموازنة التحميل، وهي Round Robin وWighted وLeast Connection. Round Robin هي الخوارزمية الافتراضية. نظرًا لأنه لم يتم تحديد أي خوارزمية في التهيئة أعلاه، سيتم تبديل الطلبات الصادرة من خادم واجهة برمجة التطبيقات الوكيل إلى خوادم الخلفية، واحدًا تلو الآخر، بين الهدف 1 والهدف 2.

يُشكّل العنصر <Path> المسار الأساسي لمعرّف الموارد المنتظم (URI) لـ TargetEndpoint جميع الخوادم المستهدفة. ولا يتم استخدامها إلا عند استخدام <LoadBalancer>. بخلاف ذلك، تجاهله. في المثال أعلاه، يصل الطلب إلى "target1" ستكون http://target1/test وما إلى ذلك للخوادم المستهدفة الأخرى.

ضبط خيارات جهاز موازنة الحمل

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

خوارزمية

تحدِّد هذه السياسة الخوارزمية التي يستخدمها <LoadBalancer>. المتاح الخوارزميات هي RoundRobin وWeighted وLeastConnections، وتم توثيق كل منها أدناه.

الترتيب الدوري

تعيد الخوارزمية الافتراضية،Round robin، توجيه طلبًا إلى كل TargetServer بالترتيب التي يتم سردها في الخوادم في اتصال HTTP لنقطة النهاية المستهدفة. على سبيل المثال:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
      </LoadBalancer>
      <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

موزون

تتيح لك خوارزمية موازنة التحميل المرجَّح ضبط أحمال تناسبية للزيارات على TargetServers. يوزّع LoadBalancer المرجّح الطلب على TargetServers بشكل مباشر. مع وزن كل TargetServer. وبالتالي، تتطلب منك الخوارزمية المرجحة تعيين سمة weight لكل TargetServer. على سبيل المثال:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
    <LoadBalancer>
      <Algorithm>Weighted</Algorithm>
      <Server name="target1">
        <Weight>1</Weight>
      </Server>
      <Server name="target2">
        <Weight>2</Weight>
      </Server>
    </LoadBalancer>
    <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

في هذا المثال، سيتم توجيه طلبَين إلى target2 لكل طلب يتم توجيهه إلى الهدف1.

أدنى اتصال بالإنترنت

تعمل موازين التحميل التي تم ضبطها لاستخدام أقل خوارزمية اتصال على توجيه الطلبات الصادرة إلى TargetServer مع أقل عدد من اتصالات HTTP المفتوحة. على سبيل المثال:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>LeastConnections</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
      </LoadBalancer>
  </HTTPTargetConnection>
  <Path>/test</Path>
</TargetEndpoint>

الحد الأقصى لعدد الإخفاقات

الحد الأقصى لعدد الطلبات التي تعذّر تنفيذها من الخادم الوكيل لواجهة برمجة التطبيقات إلى TargetServer التي تؤدي إلى تتم إعادة توجيه الطلب إلى TargetServer آخر.

يعني تعذُّر الاستجابة أنّ Apigee لا تتلقّى أي استجابة من الخادم الهدف. فعندما فسيحدث ذلك، يزيد عدّاد الفشل بمقدار واحد.

مع ذلك، عندما تتلقّى Apigee استجابة من أحد الاستهدافات، حتى إذا كانت الاستجابة هي خطأ HTTP (مثل 500)، يتم احتساب ذلك كاستجابة من الخادم الهدف وإعادة تعيين عدّاد الإخفاق. للمساعدة في ضمان حدوث استجابات سيئة HTTP (مثل 500) تزيد أيضًا من عدّاد الإخفاق لإزالة خادم غير سليم لتدوير موازنة التحميل بأسرع وقت ممكن، يمكنك إضافة عنصر <ServerUnhealthyResponse> مع <ResponseCode> العناصر الفرعية إلى تهيئة جهاز موازنة الحمل. سيحسب Edge أيضًا الردود التي تحتوي على تلك الرموز على أنها إخفاقات.

في المثال التالي، ستتم إزالة target1 من التناوب بعد خمسة تعذّر تنفيذ الطلبات، بما في ذلك بعض 5XX من الردود من الخادم الهدف.

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
        <MaxFailures>5</MaxFailures>
        <ServerUnhealthyResponse>
            <ResponseCode>500</ResponseCode>
            <ResponseCode>502</ResponseCode>
            <ResponseCode>503</ResponseCode>
        </ServerUnhealthyResponse>
      </LoadBalancer>
      <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

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

الأفضل استخدام MaxFailures > 0 مع HealthMonitor. في حالة تهيئة MaxFailures > 0، تتم إزالة TargetServer من التناوب عندما فشل الهدف عدد المرات التي تشير إليها. عندما HealthMonitor، تضع Apigee تلقائيًا وفقًا لـ إعدادات تطبيق HealthMonitor. مراجعة مراقبة السلامة لمزيد من المعلومات.

أو بدلاً من ذلك، إذا قمت بتهيئة الحد الأقصى للإخفاقات > 0، ولم تقم بتهيئة HealthMonitor، لن تُعيد Apigee تضمين TargetServer في عملية التدوير تلقائيًا بعد أن ترصد Apigee خطأ. وفي هذه الحالة، يجب عليك إعادة نشر الخادم الوكيل لواجهة برمجة التطبيقات قبل أن يعيد Apigee وضع TargetServer مرة أخرى تدوير. عرض نشر خادم وكيل لواجهة برمجة التطبيقات:

إعادة المحاولة

في حال تفعيل إعادة المحاولة، ستتم إعادة محاولة الطلب عند حدوث خطأ في الاستجابة (خطأ I/O أو مهلة HTTP). أو تتطابق الاستجابة الواردة مع قيمة تم ضبطها من قِبل "<ServerUnhealthyResponse>". راجِع قسم الحد الأقصى لعدد الإخفاقات أعلاه لمعرفة المزيد عن الإعداد <ServerUnhealthyResponse>

يتم ضبط <RetryEnabled> تلقائيًا على true. يمكنك الضبط على false لإيقاف إعادة المحاولة. على سبيل المثال:

<RetryEnabled>false</RetryEnabled>

IsFallback

يمكن ضبط TargetServer واحدًا (واحدًا فقط) باعتباره "الاحتياطي" الخادم. خادم TargetServer الاحتياطي لا يتم تضمينه في سلاسل إجراءات موازنة التحميل حتى يتم تحديد جميع خوادم TargetServer الأخرى غير متاح بواسطة جهاز موازنة الحمل. عندما يحدِّد جهاز موازنة الحمل أنّ جميع خوادم TargetServer غير متاح، يتم توجيه جميع حركة البيانات إلى الخادم الاحتياطي. على سبيل المثال:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
        <Server name="target3">
          <IsFallback>true</IsFallback>
        </Server>
      </LoadBalancer>
      <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

ينتج عن الإعداد أعلاه موازنة حمولة البيانات الدورية بين الهدفَين 1 و2 حتى. كلا الهدفين 1 و2 غير متاحين. في حال عدم توفّر الهدفَين 1 و2، يتم توجيه جميع الزيارات. لاستهداف 3.

المسار

يحدِّد المسار جزءًا من عنوان URI الذي سيتم إلحاقه بجميع الطلبات الصادرة عن TargetServer. إلى خادم الخلفية.

يقبل هذا العنصر مسار سلسلة حرفية أو نموذج رسالة. رسالة إجراء استبدال سلاسل المتغير في وقت التشغيل. على سبيل المثال، في تعريف نقطة النهاية المستهدفة التالي، يتم استخدام قيمة {mypath} للمسار:

<HTTPTargetConnection>
    <SSLInfo>
      <Enabled>true</Enabled>
    </SSLInfo>
    <LoadBalancer>
      <Server name="testserver"/>
    </LoadBalancer>
    <Path>{mypath}</Path>
</HTTPTargetConnection>

تكوين خادم هدف لـ TLS/SSL

إذا كنت تستخدم TargetServer لتحديد خدمة الخلفية وخدمة الخلفية تتطلب اتصالاً لاستخدام بروتوكول HTTPS، فيجب عليك تمكين TLS/SSL في تعريف TargetServer. هذا الإجراء ضروري لأنّ العلامة <Host> لا تتيح لك لتحديد بروتوكول الاتصال. يظهر أدناه تعريف TargetServer أحادي الاتجاه بروتوكول أمان طبقة النقل (TLS) أو طبقة المقابس الآمنة (SSL) حيثما يرسل Edge طلبات HTTPS إلى خدمة الخلفية:

<TargetServer name="target1">
  <Host>mocktarget.apigee.net</Host>
  <Port>443</Port>
  <IsEnabled>true</IsEnabled>
  <SSLInfo>
      <Enabled>true</Enabled>
  </SSLInfo> 
</TargetServer>

إذا كانت خدمة الخلفية تتطلب استخدام بروتوكول أمان طبقة النقل (TLS)/طبقة المقابس الآمنة (TLS) أو طبقة المقابس الآمنة ثنائية الاتجاه أو متبادل، فإنه يتم TargetServer باستخدام نفس إعدادات ضبط بروتوكول أمان طبقة النقل (TLS)/طبقة المقابس الآمنة (SSL) مثل TargetEndpoints:

<TargetServer  name="TargetServer 1">
    <IsEnabled>true</IsEnabled>
    <Host>www.example.com</Host>
    <Port>443</Port>
    <SSLInfo>
        <Ciphers/>
        <ClientAuthEnabled>true</ClientAuthEnabled>
        <Enabled>true</Enabled>
        <IgnoreValidationErrors>false</IgnoreValidationErrors>
        <KeyAlias>keystore-alias</KeyAlias>
        <KeyStore>keystore-name</KeyStore>
        <Protocols/>
        <TrustStore>truststore-name</TrustStore>
    </SSLInfo>
</TargetServer >

للحصول على معلومات عن سمات <SSLInfo>، مثل <Ciphers> و<ClientAuthEnabled>، يمكنك الاطّلاع على معلومات حول إعداد هذه الخصائص لمضيف افتراضي في تهيئة الدخول إلى بروتوكول أمان طبقة النقل (TLS) إلى واجهة برمجة تطبيقات بالنسبة إلى السحابة الإلكترونية الخاصة

للاطلاع على الإرشادات الكاملة حول تهيئة طبقة النقل الآمنة/طبقة المقابس الآمنة الصادرة، اطلع على تهيئة بروتوكول أمان طبقة النقل (TLS) من Edge إلى الخلفية (السحابة الإلكترونية والسحابة الإلكترونية الخاصة).

مخطط TargetServer

شاهد مخطط TargetServer والكيانات الأخرى على GitHub.

مراقبة الحالة الصحية

وتتيح لك مراقبة الصحة تحسين عمليات ضبط موازنة التحميل من خلال إجراء استطلاع فعال عناوين URL لخدمة الخلفية المحدّدة في إعدادات TargetServer مع تفعيل مراقبة الصحة، يؤدي إخفاق TargetServer إلى وضعه مرة أخرى تلقائيًا عندما تحدد أداة HealthMonitor أن TargetServer نشط.

تعمل ميزة مراقبة الصحة مع "<MaxFailures>". بدون تفعيل مراقبة الصحة، <MaxFailures> يحدد عدد الطلبات التي تعذّر تنفيذها من الخادم الوكيل لواجهة برمجة التطبيقات إلى TargetServer يؤدي إلى إعادة توجيه الطلب إلى TargetServer آخر. بعد ذلك، يتم إيقاف دوران TargetServer المخاشل إلى أن تعيد نشر الخادم الوكيل.

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

تعمل HealthMonitor كبرنامج بسيط يستدعي خدمة خلفية عبر بروتوكول TCP أو HTTP:

• يضمن عميل TCP ببساطة إمكانية فتح المقبس.
• يمكنك إعداد عميل HTTP لإرسال طلب HTTP صالح إلى خدمة الخلفية. إِنْتَ تحديد عمليات HTTP GET أو PUT أو POST أو DELETE. يجب أن تتطابق استجابة طلب أداة مراقبة HTTP مع الإعدادات التي تم ضبطها في الجزء <SuccessResponse>.

النجاحات والإخفاقات

عند تفعيل ميزة مراقبة الصحة، يبدأ Edge في إرسال عمليات التحقّق من الصحة إلى الهدف. الخادم. التحقق من الصحة هو طلب يتم إرساله إلى الخادم المستهدف ويحدد ما إذا كان ما إذا كان الخادم المستهدف سليمًا أم لا.

يمكن أن يؤدي فحص الصحة إلى إحدى النتيجتين المحتملتين:

• تمت العملية بنجاح: يعتبر الخادم المستهدف سليمًا عند اكتمال عملية التحقق بنجاح. التحقق. ويحدث هذا عادةً نتيجة لواحد أو أكثر مما يلي:
  • يقبل الخادم الهدف اتصالاً جديدًا بالمنفذ المحدّد، ويستجيب لطلب في هذا المنفذ، ثم يغلق المنفذ خلال الإطار الزمني المحدّد. تحتوي الاستجابة من الخادم الهدف على "اتصال: إغلاق"
  • يستجيب الخادم المستهدف لطلب التحقق من الصحة من خلال عرض رمز حالة HTTP 200 (OK) أو أي رمز حالة HTTP آخر تعتبره مقبولاً.
  • يستجيب الخادم الهدف لطلب التحقّق من الصحة من خلال عرض نص رسالة يتطابق مع النص المتوقَّع.

  عندما يحدد Edge أن الخادم في حالة جيدة، يستمر Edge أو يستأنف إرسال الطلبات إليه.

• تعذُّر التحقّق: قد يفشل الخادم الهدف في إجراء فحص صحي بطرق مختلفة، حسب نوع عملية الفحص. ويمكن تسجيل حالة تعذُّر الإجراء عندما يُجري الخادم الهدف ما يلي:
  • يرفض الاتصال من Edge بمنفذ التحقق من الصحة.
  • لا يستجِب طلب فحص صحّي خلال فترة زمنية محدّدة.
  • تعرض رمز حالة HTTP غير متوقع.
  • ويستجيب باستخدام نص رسالة لا يتطابق مع نص الرسالة المتوقع.

  عندما يخفق الخادم الهدف في التحقق من الصحة، تزيد Edge من عدد إخفاقات الخادم. في حال حذف أنّ عدد حالات تعذُّر هذا الخادم يستوفي الحدّ الأدنى المحدّد مسبقًا أو يتجاوزه. (<MaxFailures>)، يتوقف Edge عن إرسال الطلبات إلى ذلك الخادم.

تفعيل HealthMonitor

لإنشاء HealthMonitor، عليك إضافة العنصر <HealthMonitor> إلى بروتوكول HTTPConnection في TargetEndpoint. تهيئة الخادم الوكيل. ولا يمكنك إجراء ذلك في واجهة المستخدم. بدلاً من ذلك، يمكنك إنشاء تهيئة للخادم الوكيل قم بتحميله كملف ZIP على Edge. تهيئة الخادم الوكيل هي وصف منظم لجميع الجوانب خادم وكيل لواجهة برمجة التطبيقات. تتكون إعدادات الخادم الوكيل من ملفات XML في بنية دليل محددة مسبقًا. لمزيد من المعلومات، ، راجع خادم وكيل واجهة برمجة التطبيقات مرجع الضبط.

يمكنك استخدام HealthMonitor بسيط لتحديد IntervalInSec مع إما TCPMonitor أو HTTPMonitor. يحدد العنصر <MaxFailures> الحد الأقصى عدد الطلبات التي تعذّر تنفيذها من الخادم الوكيل لواجهة برمجة التطبيقات إلى TargetServer التي نتج عنها الطلب تتم إعادة توجيهه إلى TargetServer آخر. تكون قيمة <MaxFailures> تلقائيًا 0، ما يعني لا تنفذ Edge أي إجراء تصحيحي. عند ضبط أداة مراقبة الصحة، تأكَّد من ضبط <MaxFailures> في علامة <HTTPTargetConnection> في العلامة <TargetEndpoint> إلى قيمة غير صفرية.

TCPMonitor

تُحدِّد الإعدادات أدناه أداة HealthMonitor التي ستفحص كل TargetServer من خلال فتح الاتصال عبر المنفذ 80 كل خمس ثوانٍ. (المنفذ اختياري. في حال عدم تحديده، سيظهر منفذ TCPMonitor هو المنفذ TargetServer).

• إذا تعذَّر الاتصال أو استغرق الاتصال أكثر من 10 ثوانٍ، سيتم احتساب عدد الإخفاقات يزيد بمقدار 1 لـ TargetServer هذا.
• إذا نجح الاتصال، فسيتم إعادة ضبط عدد إخفاقات TargetServer على 0.

يمكنك إضافة HealthMonitor كعنصر ثانوي في HTTPTargetConnetion لـ TargetEndpoint كما هو موضح أدناه:

<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>
            <Port>80</Port>
        </TCPMonitor>
      </HealthMonitor>
  </HTTPTargetConnection>
. . .

أداة HealthMonitor مع عناصر إعداد TCPMonitor

يصف الجدول التالي عناصر ضبط TCPMonitor:

HTTPMonitor

سيرسِل نموذج HealthMonitor يستخدم HTTPMonitor طلب GET إلى الخلفية. الخدمة مرة واحدة كل خمس ثوانٍ. يضيف النموذج التالي عنوان تفويض HTTP الأساسي إلى ملف لطلب إرسال رسالة. تحدِّد إعدادات الاستجابة الإعدادات التي ستتم مقارنتها بالقيم الفعلية الاستجابة من خدمة الخلفية. في المثال أدناه، الاستجابة المتوقعة هي بروتوكول HTTP رمز الاستجابة 200 وعنوان HTTP مخصّص ImOK الذي تكون قيمته YourOK في حال عدم تطابق الاستجابة، سيتم التعامل مع الطلب على أنّه تعذّر إكماله. من خلال إعداد جهاز موازنة الحمل.

تتوافق أداة HTTPMonitor مع خدمات الخلفية التي تم ضبطها لاستخدام HTTP وHTTPS الأحادي. والبروتوكولات. ومع ذلك، لا تتيح هذه الخدمة ما يلي:

• بروتوكول HTTPS الثنائي الاتجاه (يُعرف أيضًا باسم بروتوكول أمان طبقة النقل (TLS)/طبقة المقابس الآمنة الثنائية (SSL)
• الشهادات الموقَّعة ذاتيًا.

لاحظ أن جميع إعدادات الطلب والاستجابة في شاشة HTTP ستكون خاصة خدمة الخلفية التي يجب استدعاؤها.

    <HealthMonitor>
      <IsEnabled>true</IsEnabled>
      <IntervalInSec>5</IntervalInSec>
      <HTTPMonitor>
        <Request>
          <IsSSL>true</IsSSL>
          <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
          <SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
          <Port>80</Port>
          <Verb>GET</Verb>
          <Path>/healthcheck</Path>
          <Header name="Authorization">Basic 12e98yfw87etf</Header>
          <IncludeHealthCheckIdHeader>true</IncludeHealthCheckIdHeader>
        </Request>
        <SuccessResponse>
          <ResponseCode>200</ResponseCode>
          <Header name="ImOK">YourOK</Header>
        </SuccessResponse>
      </HTTPMonitor>
    </HealthMonitor>
    

HealthMonitor مع عناصر إعداد HTTPMonitor

يصف الجدول التالي عناصر ضبط HTTPMonitor: