ما الجديد في API7 Enterprise 3.2.9: ترقية تكوين Health Check

مقدمة حول ميزات الفحص الصحي الجديدة

في الإصدار 3.2.9 من API7 Enterprise، تم تحسين تجربة التفاعل التكويني لعمليات الفحص الصحي بشكل شامل.

1. تم تجميع عناصر التكوين التي كانت مبعثرة سابقًا بشكل منطقي، مثل إعدادات المسبار، ومعايير تحديد العقد السليمة وغير السليمة، مما جعلها أكثر تنظيماً.

2. تم تحويل بعض أسماء عناصر التكوين المجردة إلى تعبيرات أكثر وضوحاً ودلالية، مما يسمح للمستخدمين بإدخال المعلمات ذات الصلة مباشرة من خلال تنسيق ملء الفراغات، وبالتالي فهم أفضل للآثار العملية للتكوينات.

3. أثناء تكوين العقد العلوية وعمليات الفحص الصحي، تمت إضافة المزيد من الرسائل الإرشادية لمساعدة المستخدمين على فهم العلاقة الكامنة بين العقد العلوية والفحص الصحي بشكل أفضل، مما يسهل إكمال مهام التكوين بسهولة أكبر.

المفاهيم الأساسية للفحص الصحي

في API7 Enterprise، يرتبط إعداد أولوية العقد العلوية ارتباطًا وثيقًا بآليات موازنة الحمل والفحص الصحي. عند قيام المستخدمين بتكوين عدة عقد علوية ذات أولويات مختلفة للبوابة، تقوم البوابة بتحديد العقد ذات الأولوية الأعلى أولاً أثناء موازنة الحمل. هذا يعني أنه طالما بقيت العقد ذات الأولوية الأعلى سليمة، ستستمر البوابة في توجيه حركة المرور إلى هذه العقد.

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

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

طرق تكوين الفحص الصحي

تكوين المسبار

يستخدم المسبار للكشف عن حيوية وحالة الخدمة للعقد العلوية. في APISIX، المسبار يشبه "المفتش" الذي يطرق الباب بانتظام للتحقق مما إذا كانت الخدمة العلوية تعمل بشكل صحيح. إذا وجد أي مشاكل أو إذا كانت الخدمة "غير متاحة"، فإنه يخبر APISIX: "هذه الخدمة غير متاحة حاليًا، لذا توقف عن إرسال الطلبات هنا." تتم عملية "طرق الباب" هذه من خلال المسابر.

يتضمن المسبار بشكل رئيسي عناصر التكوين التالية:

• نظام المسبار: نوع البروتوكول المستخدم بواسطة مسبار الفحص الصحي، يدعم TCP، HTTP، و HTTPS.

• التزامن: يسمح لك عنصر التكوين هذا بتعيين عدد طلبات الفحص الصحي المتزامنة. بمعنى آخر، هذا هو عدد المرات التي تريد فيها "طرق الباب" في نفس الوقت للتحقق من استجابة الخدمات العلوية. من خلال ضبط التزامن، يمكنك محاكاة الطلبات المتزامنة المحتملة في سيناريوهات العالم الحقيقي، وبالتالي تقييم أداء واستقرار الخدمات العلوية بشكل أفضل.

• المضيف: يحدد عنوان المضيف لخادم العلوي الذي سيتم فحصه. هذا يشبه تحديد أي منزل تريد "طرق بابه".

• المنفذ: رقم المنفذ للخدمة العلوية. يشبه معرفة أي باب تطرق عليه أثناء المسبار.

• المسار: إذا كنت تستخدم مسبار HTTP، فإن عنصر التكوين هذا يحدد مسار URL الذي تريد الوصول إليه. يشبه إخبار المسبار بالتحقق من الغرفة المحددة بمجرد دخولها.

معايير تحديد العقد السليمة

بخصوص تحديد العقد السليمة، يقوم النظام بفحص العقد التي تم تحديدها سابقًا على أنها غير سليمة بشكل منتظم على الفاصل الزمني الذي يحدده المستخدم (بالثواني) لضمان الكشف في الوقت المناسب والتعامل الصحيح مع أي شذوذ عابر في العقد.

إذا كان المسبار يستخدم بروتوكول TCP، يتم اعتبار العقدة سليمة بعد أن ينجح المسبار في الاتصال بالعقدة العلوية بعدد المرات التي يحددها المستخدم.

إذا كان المسبار يستخدم بروتوكول HTTP/HTTPS، يعتبر النظام العقدة سليمة فقط عندما تتلقى بشكل مستمر طلبات مسبار برموز حالة محددة (مثل 200 و 302) من العقدة. هذا يعني أن العقدة تعتبر تعمل بشكل صحيح فقط عندما تعيد هذه الرموز المحددة بشكل مستمر.

معايير تحديد العقد غير السليمة

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

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

أفضل الممارسات للفحص الصحي

اختيار نوع المسبار المناسب

• مسبار TCP: مناسب للسيناريوهات التي تتطلب فقط تأكيد ما إذا كان منفذ الخدمة مفتوحًا ويمكن الوصول إليه. على سبيل المثال، قد تحتاج خدمة قاعدة بيانات فقط إلى مسبار TCP لتأكيد فتح المنفذ.

• مسبار HTTP/HTTPS: أكثر ملاءمة للسيناريوهات التي تتطلب التحقق من أن الاتصال الشبكي ليس فقط طبيعيًا ولكن أيضًا أن الخدمة يمكنها التعامل مع الطلبات بشكل صحيح. على سبيل المثال، لخادم ويب أو خدمة API، نحتاج إلى التأكد من أنه يمكنه ليس فقط استقبال الاتصالات ولكن أيضًا إرجاع الصفحات أو البيانات الصحيحة.

تكوين معلمات الفحص الصحي بشكل معقول

عند تكوين الفحص الصحي، انتبه إلى عدة معلمات رئيسية:

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

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

• المهلة: الوقت الذي ينتظره المسبار لاستجابة الخدمة. إذا لم تستجب الخدمة خلال هذا الوقت، يعتبر المسبار الخدمة غير سليمة. يجب تعيين هذه القيمة وفقًا لوقت الاستجابة الفعلي للخدمة.

• عدد المحاولات: عدد المرات التي يحاول فيها المسبار الاتصال قبل اعتبار الخدمة غير سليمة. يجب أن تكون هذه القيمة معتدلة لتجنب الأحكام الخاطئة.

تعديل الاستراتيجيات بناءً على الأعمال

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

تمكين التحقق من طلبات العميل بشكل مناسب

يمكن أن يساعد التحقق من طلبات العميل في تحديد حالة الخدمة بناءً على طلبات الأعمال الفعلية، خاصة لتحديد المشاكل المرتبطة ارتباطًا وثيقًا بمنطق الأعمال. ومع ذلك، قد لا يكون مناسبًا لكل سيناريو أعمال.

1. الخدمات منخفضة الحركة: إذا كانت حركة الخدمة منخفضة، قد لا توفر عمليات الفحص الصحي السلبية بناءً على طلبات العملاء نقاط بيانات كافية لتقييم حالة الخدمة بدقة. في مثل هذه الحالات، قد يكون الاعتماد على عمليات الفحص النشطة أكثر موثوقية.

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

3. وجود أنظمة مراقبة أخرى: إذا تم نشر أنظمة مراقبة ناضجة بالفعل في المؤسسة، قادرة على التقاط وتحليل حالة الخدمة في الوقت الفعلي، قد لا تكون عمليات الفحص الصحي السلبية ضرورية لتجنب تكرار البيانات والتعقيد الإضافي.

الخلاصة

الفحص الصحي هو جانب حاسم لضمان التوافر العالي لبوابات API. في الإصدار 3.2.9 من API7 Enterprise، قمنا بتحسين تكوين التفاعل للفحص الصحي بشكل شامل، مما يبسط العمليات ويعزز تجربة المستخدم.

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