تنفيذ Fallback باستخدام API Gateway

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

تنفيذ البدائل باستخدام APISIX

لتنفيذ آلية بديل باستخدام APISIX، يمكنك استخدام ميزة أولويات المنبع المدمجة أو استخدام مكوّن إعادة كتابة الاستجابة لإرجاع استجابة محددة مسبقًا عند فشل استدعاء الخدمة. إليك مثال خطوة بخطوة لكيفية إعداد كلتا الطريقتين للبديل.

المتطلبات الأساسية

يفترض هذا الدليل أن الأدوات التالية مثبتة محليًا:

• قبل البدء، من الجيد أن يكون لديك فهم أساسي لـ APISIX. الإلمام بـ بوابة API، والمفاهيم الرئيسية مثل المسارات، المنبع، واجهة برمجة التطبيقات الإدارية، المكوّنات الإضافية، وبروتوكول HTTP سيكون مفيدًا أيضًا.
• يتم استخدام Docker لتثبيت etcd وAPISIX في حاويات.
• قم بتثبيت cURL لإرسال الطلبات إلى الخدمات للتحقق.

بدء مشروع Docker لـ APISIX

يستفيد هذا المشروع من ملف تكوين Docker Compose المحدد مسبقًا لإعداد ونشر وتشغيل APISIX وetcd وPrometheus وخدمات أخرى باستخدام أمر واحد. أولاً، قم باستنساخ مستودع apisix-docker على GitHub، وافتحه في محررك المفضل، وانتقل إلى مجلد example، وابدأ المشروع ببساطة عن طريق تشغيل أمر docker compose up في طرفية من مجلد جذر المشروع.

عند بدء المشروع، يقوم Docker بتنزيل أي صور يحتاجها للتشغيل. كما يقوم بتشغيل خدمتين خلفيتين مثاليتين web1 وweb2. يمكنك رؤية القائمة الكاملة للخدمات في ملف docker-compose.yaml.

البديل مع تمكين أولويات المنبع في APISIX

يمكنك إعداد كل عقدة منبع بمستوى معين من الأولوية لتمكينها. عندما تفشل نقطة النهاية للعقدة ذات الأولوية الأعلى، يمكن لبوابة API إعادة توجيه الحركة إلى عقدة ثانوية ذات أولوية أقل. الأولوية الافتراضية لجميع العقد هي 0، ويمكن تكوين العقد ذات الأولوية السالبة كنسخة احتياطية.

قم بإنشاء مسار إلى الخدمتين وتكوين سمة الأولوية لكل عقدة خدمة منبع:

curl "http://127.0.0.1:9180/apisix/admin/routes" -H "X-API-KEY: edd1c9f034335f136f87ad84b625c8f1" -X PUT -d '
{
   "id":"backend-service-route",
   "methods":[
      "GET"
   ],
   "uri":"/get",
   "upstream":{
      "nodes":[
         {
            "host":"web1",
            "port":80,
            "weight":1,
            "priority":0
         },
         {
            "host":"web2",
            "port":80,
            "weight":1,
            "priority":-1
         }
      ]
   }
}'

• methods: يحدد هذا طريقة HTTP التي سيطابقها هذا المسار. في هذه الحالة، تم تعيينه لمطابقة طلبات GET.
• uri: هذا هو المسار الذي سيطابقه المسار. لذا، أي طلب GET إلى /get سيتم التعامل معه بواسطة هذا المسار.
• nodes: هذا عبارة عن مجموعة من الخوادم الخلفية. كل كائن في المصفوفة يمثل خادمًا مع host، port، وweight. يتم استخدام weight لتحقيق التوازن في التحميل؛ في هذه الحالة، كلاهما لديه وزن 1، مما يعني عادةً أنهما سيشاركان الحركة بالتساوي.
• priority: هذا تكوين إضافي للعقدتين (web1، web2). يتم استخدام حقل priority لتحديد الترتيب الذي يتم به اختيار العقد. سيتم استخدام العقدة ذات الأولوية الأقل (رقم سالب أعلى) فقط إذا كانت جميع العقد ذات الأولوية الأعلى (أرقام سالبة أقل أو أرقام موجبة) غير متاحة.

تحقق مما إذا كنت تحصل فقط على استجابة من خدمة web1 عند إرسال طلب إلى المسار:

curl "http://127.0.0.1:9080/get"

يجب أن ترى استجابة مشابهة لما يلي:

hello web1

هذا يعني أن web1 تم تنفيذه أولاً لأنه يعمل. الآن أوقف حاوية خدمة web1 للتحقق مما إذا كان APISIX يتحول إلى خدمة web2.

docker container stop example-web1-1

الآن إذا أرسلت طلبًا آخر إلى المسار، ستحصل على استجابة من الخدمة البديلة التي حددناها.

curl "http://127.0.0.1:9080/get"
hello web2

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

البديل مع مكوّن إعادة كتابة الاستجابة في APISIX

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

إذا اتبعت الطريقة الأولى، أعد تشغيل حاوية خدمة web1 في Docker:

docker container start example-web1-1

لاستخدام مكوّن إعادة كتابة الاستجابة للبديل، تحتاج إلى تكوينه في مسار. إليك مثال لكيفية تمكين المكوّن باستخدام أمر curl:

curl "http://127.0.0.1:9180/apisix/admin/routes" -H "X-API-KEY: edd1c9f034335f136f87ad84b625c8f1" -X PUT -d '
{
   "id":"backend-service-route",
   "methods":[
      "GET"
   ],
   "uri":"/get",
   "plugins":{
      "response-rewrite":{
         "status_code":200,
         "body":"{\"message\":\"This is a fallback response when the service is unavailable\"}",
         "vars":[
            [
               "status",
               "==",
               503
            ]
         ]
      }
   },
   "upstream":{
      "nodes":{
         "web1:80":1
      }
   }
}'

في المثال أعلاه، قمنا بتعريف خدمة خلفية واحدة (web1:80) حيث يجب توجيه الحركة عند مطابقة هذا المسار. إذا استجابت الخدمة المنبع (web1:80) برمز حالة 503 Service Unavailable، فسيقوم مكوّن إعادة كتابة الاستجابة بتعديل الاستجابة ليكون لها رمز حالة 200 OK مع جسم JSON مخصص. هذا يخلق بشكل فعال استجابة بديلة عندما تكون الخدمة المنبع غير متاحة.

"vars": [["status", "==", 503]]: تخبر هذه الحالة المكوّن بتطبيق إعادة الكتابة فقط عندما يكون رمز حالة الاستجابة الأصلي هو 503 Service Unavailable.

الآن إذا أرسلت طلبًا إلى المسار، يجب أن تحصل على استجابة معدلة:

curl "http://127.0.0.1:9080/get"

{"message":"This is a fallback response when the service is unavailable"}

تحديات تنفيذ آلية البديل

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

صعوبة اختبار منطق البديل

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

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

البدائل نفسها يمكن أن تفشل

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

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

البدائل لديها مخاطر تشغيلية

قد يؤدي تنفيذ بديل إلى إدخال نقاط فشل جديدة، مثل قاعدة بيانات ثانوية غير متزامنة مع الأساسية، مما يؤدي إلى تناقضات في البيانات.

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

البدائل تحتوي على أخطاء كامنة ومضخمة

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

يدعم APISIX الاختبار المستمر A/B والإصدارات التدريجية، مما يسمح للفرق باختبار مسارات البديل في الإنتاج مع نسبة صغيرة من الحركة. يمكن أن يساعد هذا التعرض المستمر في الكشف عن الأخطاء الكامنة قبل أن تصبح حرجة.

البدائل نادرًا ما يتم اختبارها

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

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

الخلاصة

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

موارد ذات صلة

• 10 أنماط تصميم مرونة API الشائعة مع بوابة API
• أفضل الممارسات لبناء APIs موثوقة