10 أنماط تصميم شائعة لمرونة API مع بوابة API
November 1, 2023
مرونة API تتعلق ببناء واجهات برمجة تطبيقات قوية يمكنها تحمل مجموعة متنوعة من التحديات، مما يضمن استمرارها في العمل بشكل فعال. تلعب بوابات API دورًا رئيسيًا في ذلك، حيث تعمل كنقطة دخول للطلبات الخارجية وتدير الاتصال بين الخدمات المختلفة مع مراعاة أنماط مرونة API الشائعة. واحدة من بوابات API مفتوحة المصدر الشهيرة، Apache APISIX، توفر مجموعة متنوعة من الميزات لتعزيز مرونة وقوة واجهات برمجة التطبيقات. في هذه المقالة، سنستكشف 10 أنماط تصميم شائعة لمرونة API وكيف يمكن تنفيذها باستخدام APISIX.
إليك قائمة بجميع أنماط مرونة API العشرة:
- تحديد معدل الطلبات.
- إعادة المحاولة.
- المهلة الزمنية.
- الاستجابة الاحتياطية.
- التخزين المؤقت.
- التكرار.
- فحوصات الصحة.
- قاطع الدائرة.
- الحاجز.
- حقن الأعطال.
ما هي مرونة API؟
تشير مرونة API إلى قدرة واجهة برمجة التطبيقات على أداء وظائفها المقصودة بشكل متسق وموثوق، حتى في مواجهة الأخطاء أو الزيادة الكبيرة في حركة المرور أو الظروف غير المتوقعة. لا يتعلق الأمر بتجنب الفشل، بل بقبول حقيقة أن الفشل سيحدث والاستجابة له بطريقة تجنب التوقف عن العمل أو فقدان البيانات. الهدف من المرونة هو إعادة التطبيق إلى حالة عمل كاملة بعد الفشل. تم بناء واجهات برمجة التطبيقات المرنة للتعامل مع الفشل بشكل أنيق، سواء كان هذا الفشل ناتجًا عن الواجهة نفسها، أو من الخدمات التابعة، أو بسبب عوامل خارجية مثل مشاكل الشبكة أو التأخير، أو عدم توافق إصدارات API، وغيرها من المشاكل التي قد تنشأ بسبب تغيرات في البيئة أو سلوك المستخدم غير المتوقع.
لماذا مرونة API في بوابة API؟
تتضمن العديد من أطر تطوير البرمجيات الحالية مجموعة من الممارسات والأنماط المصممة لضمان بقاء واجهات برمجة التطبيقات متاحة وسريعة الاستجابة ودقيقة. ومع ذلك، فإن تنفيذ مرونة API على مستوى بوابة API، بدلاً من الخدمات الفردية أو في مكان آخر في النظام، يوفر عدة مزايا استراتيجية.
1. التحكم المركزي: تعمل بوابة API كنقطة دخول مركزية لجميع طلبات API، مما يوفر فرصة فريدة لإدارة وتطبيق أنماط المرونة عبر جميع الخدمات بطريقة موحدة. هذا التمركز يبسط تنفيذ وصيانة ميزات المرونة.
2. الاتساق: من خلال التعامل مع المرونة في بوابة API، تضمن نهجًا متسقًا للتعامل مع الفشل، وتحديد معدل الطلبات، والمهلات الزمنية، وغيرها من استراتيجيات المرونة عبر جميع الخدمات. هذا الاتساق ضروري للحفاظ على سلوك نظام موثوق ومتوقع.
3. تقليل التعقيد: يمكن أن يؤدي تنفيذ ميزات المرونة في كل خدمة صغيرة إلى تكرار الجهود وزيادة التعقيد. تعمل بوابة API على تجريد هذه الاهتمامات، مما يسمح لمطوري الخدمات بالتركيز على منطق الأعمال بدلاً من التعامل مع المرونة.
4. تحسين استخدام الموارد: يمكن لبوابة API إدارة الموارد بكفاءة وتوزيع حركة المرور، مما يضمن عدم إرهاق أي خدمة واحدة. يساهم هذا التوازن في الحمل في المرونة العامة للنظام.
5. مراقبة وتسجيل أسهل: وجود نقطة واحدة تمر من خلالها جميع حركة مرور API يجعل من السهل مراقبة صحة خدماتك وتسجيل أي مشاكل. هذه النظرة المركزية لا تقدر بثمن لتحديد المشاكل والاستجابة لها بسرعة.
6. تبسيط الأمان: يمكن تطبيق إجراءات الأمان مثل المصادقة والتفويض والتشفير بشكل متسق في بوابة API، مما يضمن حماية جميع الخدمات دون الحاجة إلى تكوينات زائدة عن الحاجة.
7. تحسين الأداء: يمكن لبوابة API تنفيذ التخزين المؤقت وتجميع الاستجابات، مما يقلل من عدد الطلبات إلى الخدمات الخلفية ويحسن الأداء العام للنظام.
8. التدهور اللطيف: في حالة فشل خدمة ما، يمكن لبوابة API إعادة توجيه حركة المرور أو تقديم استجابات احتياطية، مما يضمن تدهور النظام بشكل لطيف واستمرار توفير الوظائف.
9. استعادة أسرع: الطبيعة المركزية لبوابة API تسمح بتنفيذ الإصلاحات والتحديثات بسرعة، مما يضمن إمكانية استعادة النظام إلى وظائفه الكاملة بسرعة بعد الفشل.
10. تبسيط تفاعل العميل: يحتاج العملاء إلى التفاعل فقط مع بوابة API، التي توفر واجهة متسقة وموثوقة، مما يجرد تعقيد الخدمات الصغيرة الأساسية.
من وجهة نظر التطوير، فإن نهج بوابة API يقلل أيضًا من الوقت اللازم لتنفيذ أنماط المرونة الشائعة. دعونا نكتشف كل نمط في مثال الاتصال بين الخدمات في تطبيق مؤتمر نموذجي ونفهم كيفية تمكينها.
يركز هذا المنشور بشكل أساسي على الجزء النظري ويوفر مراجع للوثائق ذات الصلة. يمكن للمطورين تنفيذ هذه الأنماط من خلال التحقق من كل رابط واتباع الأدلة المقدمة. مع APISIX، يمكن تكوين أنماط التصميم هذه باستخدام واجهة برمجة التطبيقات الإدارية، أو ملف YAML ثابت أو لوحة تحكم APISIX.
1. تحديد معدل الطلبات
كما يوحي الاسم، يتحكم تحديد معدل الطلبات في عدد الطلبات التي يمكن للعميل تقديمها في فترة زمنية معينة. توفر APISIX مكونًا إضافيًا limit-req لتكوين تحديد معدل الطلبات. يسمح لك هذا المكون الإضافي بتحديد القواعد بناءً على خصائص الطلبات الفردية (الكثير من مستخدم معين، أو تطبيق عميل، أو موقع) لتحديد الطلبات، مما يضمن عدم إرهاق واجهة برمجة التطبيقات بالعديد من الطلبات.
يمكن أيضًا استخدام سياسة تحديد معدل الطلبات للحد من الوصول للمستخدمين غير المصرح لهم. تحقق من الدليل لمعرفة كيفية استخدام المكون الإضافي لتحديد معدل الطلبات.
2. إعادة المحاولة
يتضمن نمط إعادة المحاولة إعادة محاولة طلب API تلقائيًا إذا فشل. مع APISIX، يمكنك تكوين آلية إعادة المحاولة لكائن Upstream لتحديد عدد المحاولات والشروط التي يجب فيها إعادة المحاولة.
من خلال تكوين Upstream بخصائص إعادة المحاولة، ترسل APISIX طلبات إعادة محاولة تلقائية إلى خدمة Attendee الخلفية إذا فشل الطلب السابق بسبب مهلة زمنية أو مشكلة في الشبكة.
3. المهلة الزمنية
يضمن تحديد مهلة زمنية ألا يتوقف الطلب إلى الأبد إذا كانت الخدمة الخلفية غير مستجيبة. تسمح لك APISIX بتكوين المهلات الزمنية لواجهات برمجة التطبيقات الخاصة بك في نفس تكوين Upstream، مما يضمن إنهاء الطلبات إذا استغرقت وقتًا طويلاً للاستجابة.
في حالة استجابة خدمة Attendee ببطء، يمكن لـ APISIX تطبيق نمط الفشل السريع والاستجابة لطلب تطبيق العميل بسرعة لتحسين استجابة النظام العام.
4. الاستجابة الاحتياطية
يوفر نمط الاستجابة الاحتياطية استجابة افتراضية عندما تكون الخدمة غير متاحة. تسمح لك APISIX بتحديد أولويات Upstream عندما يفشل نقطة النهاية الأساسية، يمكن لبوابة API إعادة توجيه حركة المرور إلى خدمة ثانوية أو إرجاع استجابة محددة مسبقًا باستخدام مكون إضافي response-rewrite في حالة فشل الخدمات مثل HTTP 500.
أو يمكنك استخدام مكون إضافي proxy-cache لتخزين الاستجابات وتقديمها عندما تكون الخدمة الخلفية معطلة. على سبيل المثال، يعرض التطبيق المحمول قائمة الحضور المخزنة مؤقتًا عندما تكون خدمة Attendee معطلة.
5. التخزين المؤقت
يمكن أن يقلل تخزين الاستجابات بشكل كبير من الحمل على خدماتك الخلفية. توفر APISIX مكونًا إضافيًا proxy-cache يسمح لك بتخزين الاستجابات وتقديمها مباشرة من بوابة API، مما يقلل من زمن الاستجابة ويحسن الأداء.
تحقق من برنامج تعليمي لتخزين استجابات API لمعرفة كيفية استخدام مكون proxy-cache الإضافي.
6. التكرار
توفر كل بوابة API ميزة شائعة مثل موازنة الحمل التي توزع طلبات API الواردة عبر خدمات خلفية متعددة (عقد أو مثيلات). وجود مثيلات زائدة يجعل النظام أكثر قوة ضد تلك الأحداث غير المنتظمة. تدعم APISIX خوارزميات مختلفة لموازنة الحمل مثل round-robin، وأقل اتصالات، والتجزئة المتسقة.
في حالة خدمة Attendee، يمكنك تشغيل مثيلين وإذا تعطل الخادم A، يمكن تقديم الطلبات من الخادم الثاني.
7. فحوصات الصحة
فحص الصحة هو آلية تحدد ما إذا كانت الخدمات الخلفية صحية أو غير صحية بناءً على استجابتها. تحدد APISIX ما إذا كانت الخدمة متاحة أم لا باستخدام فحوصات الصحة النشطة لـ Upstream. مع تمكين فحوصات الصحة، ستقوم APISIX فقط بتوجيه الطلبات إلى الخدمات الخلفية التي تعتبر صحية، ولن تقوم بتوجيه الطلبات إلى الخدمات التي تعتبر غير صحية.
للتحقق من صحة API بشكل دوري، تحتاج APISIX إلى مسار HTTP لنقطة نهاية الصحة لخدمة Upstream. لذلك، تحتاج أولاً إلى إضافة نقطة نهاية /health لخدمة Attendee.
8. قاطع الدائرة
يمنع نمط قاطع الدائرة النظام من إجراء مكالمات إلى خدمة من المحتمل أن تفشل، وبالتالي يحمي النظام من الفشل المتتالي. توفر APISIX خيارين لتنفيذ وظيفة قاطع الدائرة: استخدام مكون إضافي api-breaker في تكوين Route أو تمكين فحوصات الصحة السلبية لـ Upstream. كلتا الطريقتين تتعاملان مع الفشل وتمنعان الخدمات الخلفية من محاولات إعادة المحاولة المستمرة إذا فشلت الخدمة أو كانت بطيئة الأداء.
تراقب APISIX عدد حالات الفشل الأخيرة التي حدثت وتستخدم هذه المعلومات لتقرير ما إذا كانت ستسمح للعملية بالمضي قدمًا، أو ببساطة إرجاع استثناء على الفور.
9. الحاجز
يعزل نمط الحاجز العناصر داخل التطبيق، مما يضمن أنه إذا فشل جزء من النظام أو كان تحت حمل ثقيل، فإن الأجزاء الأخرى من النظام تستمر في العمل. لضمان أن حركة المرور الثقيلة أو المشاكل في عمليات القراءة من خدمة Attendee لا تؤثر على توفر وأداء عمليات الكتابة إلى خدمة Attendee، يمكنك تنفيذ نمط الحاجز باستخدام APISIX.
يمكنك إنشاء نقاط نهاية Route منفصلة في بوابة API لعقدتي Upstream بحيث يتم توجيه جميع طلبات الكتابة إلى الخدمة A وجميع طلبات القراءة إلى الخدمة B.
10. اختبار الفوضى
يمكن أن يساعد اختبار الفوضى في ضمان أن واجهة برمجة التطبيقات مرنة في بيئات الإنتاج. باستخدامه، يمكنك تقييم وتعزيز مرونة تطبيقك أو واجهات برمجة التطبيقات للخدمات الصغيرة ضد أنواع مختلفة من الفشل، مما يعزز الموثوقية. تتيح هذه الطريقة إدخال تأخيرات متعمدة وإنهاء الطلبات قسريًا برموز أخطاء محددة، مما يسهل محاكاة سيناريوهات سلبية مختلفة بما في ذلك انقطاعات الخدمة، والطلب الزائد على الخدمة، والتأخيرات الكبيرة في الشبكة، وتجزئة الشبكة.
يوفر مكون APISIX Fault Injection Plugin أيضًا نفس الآلية لمحاكاة سيناريوهات الفشل المختلفة مثل الأخطاء أو التأخيرات في خدمة Attendee لاختبار كيفية تفاعل تطبيق العميل معها.
الخلاصة
في هذه المدونة، استعرضنا 10 أنماط تصميم شائعة لمرونة API، ووضحنا كيفية تنفيذها بشكل فعال باستخدام APISIX. من خلال تركيز استراتيجيات المرونة على مستوى بوابة API، يمكن للمنظمات تحقيق إدارة متسقة ومبسطة وفعالة لحركة مرور API والتعامل مع الأخطاء.