أداء واجهة برمجة التطبيقات: تحديد المعدل وترقيم الصفحات والمعالجة غير المتزامنة

**واجهة برمجة التطبيقات (API) الخاصة بك تكون بنفس سرعة أبطأ نقطة نهاية لها في ظل التحميل الأقصى. ** يمكن لنقطة نهاية واحدة غير محسنة تحتفظ باتصالات قاعدة البيانات لمدة 5 ثوانٍ أن تستنفد مجموعة الاتصال الخاصة بك وتتسبب في حالات الفشل المتتالية عبر النظام الأساسي بأكمله. تركز هندسة أداء واجهة برمجة التطبيقات (API) على ثلاث ركائز: حماية واجهة برمجة التطبيقات (API) الخاصة بك من التحميل الزائد (تحديد المعدل)، والتعامل مع مجموعات البيانات الكبيرة بكفاءة (ترقيم الصفحات)، ونقل العمليات باهظة الثمن خارج دورة الطلب (المعالجة غير المتزامنة).

الوجبات الرئيسية

• مجموعة الرمز المميز والنافذة المنزلقة هما خوارزميتان تحددان المعدل وتغطيان 95% من حالات الاستخدام - اختر بناءً على ما إذا كنت تريد تحمل الاندفاع أو التنفيذ الصارم
• يتفوق ترقيم الصفحات المستند إلى المؤشر على ترقيم الصفحات المتوازن لمجموعات البيانات الكبيرة لأنه يتجنب حساب الصفوف التي تم تخطيها
• تعمل المعالجة غير المتزامنة مع قوائم انتظار المهام على تقليل أوقات استجابة P95 عن طريق نقل إرسال البريد الإلكتروني وإنشاء PDF وتسليم خطاف الويب خارج مسار الطلب
• يؤدي ضغط الاستجابة باستخدام Brotli إلى تقليل أحجام الحمولة بنسبة 70-85%، مما يترجم مباشرة إلى عرض أسرع من جانب العميل

---

خوارزميات تحديد المعدل

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

دلو الرمز المميز

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

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

مثال لتهيئة واجهة برمجة تطبيقات التجارة الإلكترونية:

• حجم الدلو: 100 قطعة
• معدل إعادة التعبئة: 10 رموز في الثانية
• يتيح ذلك دفعات تصل إلى 100 طلب مع الحفاظ على 10 طلبات في الثانية على المدى الطويل

عداد النافذة المنزلقة

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

بالنسبة لنافذة مدتها 60 ثانية يتم تقييمها بعد 45 ثانية، يكون العدد الفعال هو: (عدد النوافذ السابقة * 0.25) + (عدد النوافذ الحالية). يؤدي هذا إلى التخلص من مشكلة الاندفاع الحدودي للنوافذ الثابتة دون تخزين الطوابع الزمنية للطلبات الفردية.

التنفيذ مع Redis

Redis هو مخزن الدعم القياسي لتحديد المعدل الموزع لأنه يوفر عمليات الزيادة الذرية باستخدام TTL. استخدم INCR مع EXPIRE للنوافذ الثابتة، أو المجموعات المصنفة باستخدام ZADD وZRANGEBYSCORE للنوافذ المنزلقة. بالنسبة لحاوية الرمز المميز، توفر البرامج النصية لـ Redis Lua عمليات فحص وتقليل ذرية.

رؤوس تحديد المعدل تنقل الحدود إلى مستهلكي واجهة برمجة التطبيقات:

• X-RateLimit-Limit -- الحد الأقصى للطلبات المسموح بها في النافذة
• X-RateLimit-Remaining -- الطلبات المتبقية في النافذة الحالية
• X-RateLimit-Reset -- الطابع الزمني لنظام Unix عند إعادة ضبط النافذة
• Retry-After -- ثانية حتى يجب على العميل إعادة المحاولة (على 429 ردًا)

---

استراتيجيات ترقيم الصفحات

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

إزاحة الصفحات

يستخدم ترقيم الصفحات في الإزاحة عبارات SQL LIMIT وOFFSET. يطلب العميل ?page=3&limit=20، ويترجم الخادم إلى OFFSET 40 LIMIT 20.

المزايا:

• سهولة التنفيذ والفهم
• يمكن للعملاء الانتقال إلى أي صفحة مباشرة
• العدد الإجمالي يمكّن واجهة المستخدم "الصفحة X من Y".

عيوب:

• يتدهور الأداء مع الإزاحات العالية - لا يزال OFFSET 1000000 يقوم بفحص 1,000,000 صف قبل عرض النتائج
• نتائج غير متناسقة عند تغيير البيانات بين الصفحات (تتغير الصفوف عند إدراج بيانات جديدة أو حذفها)
• يمكن أن يكون استعلام العدد الإجمالي (COUNT(*)) مكلفًا في الجداول الكبيرة

ترقيم الصفحات على أساس المؤشر

يستخدم ترقيم الصفحات المستند إلى المؤشر مؤشرًا غير شفاف (عادةً ما يكون مفتاحًا أساسيًا مشفرًا أو طابعًا زمنيًا) لتحديد الموضع في مجموعة النتائج. يطلب العميل ?cursor=abc123&limit=20، ويستخدم الخادم المؤشر كعبارة WHERE: WHERE id > decoded(abc123) LIMIT 20.

المزايا:

• أداء متسق بغض النظر عن موضعه في مجموعة البيانات - لا يوجد مسح للأوفست
• نتائج مستقرة حتى عند تغير البيانات بين الصفحات
• ملاءمة طبيعية للتمرير اللانهائي والخلاصات في الوقت الفعلي

عيوب:

• لا يمكن الانتقال إلى الصفحات العشوائية (لا يوجد "اذهب إلى الصفحة 50")
• أكثر تعقيدًا في التنفيذ، خاصة مع أوامر الفرز متعددة الأعمدة
• يجب تقديم العدد الإجمالي بشكل منفصل إذا لزم الأمر

ما هو ترقيم الصفحات الذي يجب استخدامه؟

تنسيق الاستجابة للصفحات

تشتمل استجابة ترقيم الصفحات المصممة جيدًا على البيانات الوصفية التي يحتاج العملاء إلى التنقل فيها:

{
  "data": [],
  "pagination": {
    "total": 15432,
    "limit": 20,
    "hasMore": true,
    "nextCursor": "eyJpZCI6MTAwfQ=="
  }
}

---

المعالجة غير المتزامنة مع قوائم انتظار المهام

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

نمط قائمة انتظار المهام

1. تقوم نقطة نهاية واجهة برمجة التطبيقات (API) بالتحقق من صحة الطلب وإنشاء سجل وظيفة
2. يتم وضع المهمة في قائمة الانتظار (Redis، RabbitMQ، SQS)
3. تعود واجهة برمجة التطبيقات (API) على الفور باستجابة مقبولة 202 ومعرف الوظيفة
4. تلتقط العملية المنفذة المهمة وتنفذها بشكل غير متزامن
5. يقوم العميل باستطلاع حالة الوظيفة أو يتلقى رد اتصال عبر الويب عند الانتهاء

حالات الاستخدام غير المتزامن الشائعة

إرسال البريد الإلكتروني - تستغرق عمليات SMTP ما بين 500 مللي ثانية إلى 3 ثوانٍ حسب الموفر. يؤدي وضع رسائل البريد الإلكتروني في قائمة الانتظار إلى تقليل وقت استجابة واجهة برمجة التطبيقات (API) ويسمح بمنطق إعادة المحاولة للفشل العابر دون حظر المستخدم.

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

تسليم الخطاف عبر الويب - تعتمد خطافات الويب الصادرة على توفر خادم الطرف الثالث. تسليم خطاف الويب في قائمة الانتظار مع إعادة محاولة التراجع الأسي (1 ثانية، 2 ثانية، 4 ثوانٍ، 8 ثوانٍ، حتى 5 دقائق) للتعامل مع حالات الفشل المؤقتة دون حظر نظامك.

استيراد البيانات وتصديرها - يجب ألا تتم معالجة تحميلات ملف CSV التي تحتوي على 100000 صف أبدًا في دورة الطلب. اقبل التحميل وأرجع معرف الوظيفة وقم بمعالجة الصفوف على دفعات.

اختيار قائمة الانتظار

---

تحسين الاستجابة

وبعيدًا عن منطق التطبيق، يمكن تحسين الاستجابة نفسها من حيث الحجم وسرعة التسليم.

الضغط

تمكين ضغط الاستجابة لتقليل أحجام الحمولة عبر الشبكة. تعمل خوارزميات الضغط الحديثة على تقليل الحمولات النصية بشكل كبير (JSON وHTML وCSS وJavaScript).

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

اختيار الحقل

السماح لعملاء واجهة برمجة التطبيقات (API) بطلب الحقول التي يحتاجون إليها فقط. يقوم GraphQL بذلك بطبيعته، ولكن يمكن لواجهات REST APIs دعم اختيار الحقل باستخدام معلمة استعلام ?fields=id,name,price. يؤدي هذا إلى تقليل حجم الحمولة ويمكنه تحسين استعلامات قاعدة البيانات عن طريق تحديد الأعمدة المطلوبة فقط.

رؤوس التخزين المؤقت للاستجابة

قم بتعيين رؤوس التحكم في ذاكرة التخزين المؤقت المناسبة على استجابات واجهة برمجة التطبيقات. يمكن لنقاط نهاية القائمة العامة (المنتجات والفئات) استخدام Cache-Control: public, max-age=300 للتخزين المؤقت لمدة 5 دقائق. يجب أن تستخدم نقاط النهاية التي تمت مصادقتها Cache-Control: private, no-cache لمنع التخزين المؤقت لـ CDN مع السماح بالتخزين المؤقت للمتصفح مع إعادة التحقق.

لمزيد من المعلومات حول إستراتيجيات التخزين المؤقت، راجع دليلنا التفصيلي حول التخزين المؤقت لـ Redis وCDN وHTTP.

---

إدارة الاتصال

تعتبر اتصالات قاعدة البيانات وHTTP موارد محدودة يجب إدارتها بعناية تحت التحميل.

تجمع اتصال قاعدة البيانات

يحتفظ تجمع الاتصال بمجموعة من اتصالات قاعدة البيانات القابلة لإعادة الاستخدام. بدون التجميع، يفتح كل طلب لواجهة برمجة التطبيقات (API) اتصالاً جديدًا بقاعدة البيانات (50-100 مللي ثانية) ويغلقه بعد الاستجابة. من خلال التجميع، تستعير الطلبات الاتصالات من المجمع وتعيدها عند الانتهاء.

معادلة حجم حوض السباحة: الاتصالات = (عدد_الأساسيات * 2) + عدد_المغزل_الفعال. بالنسبة لخادم رباعي النواة مزود بتخزين SSD، يعد إجراء 10-20 اتصالًا لكل مثيل تطبيق نقطة بداية جيدة. مراقبة استخدام المجمع - إذا تجاوز بانتظام 80%، قم إما بزيادة حجم المجمع أو تحسين مدة الاستعلام.

إبقاء HTTP على قيد الحياة

تمكين بقاء HTTP على قيد الحياة للاتصالات بالخدمات الأولية (قواعد البيانات، Redis، واجهات برمجة التطبيقات الخارجية). يؤدي هذا إلى إعادة استخدام اتصالات TCP بدلاً من إنشاء اتصالات جديدة لكل طلب، مما يؤدي إلى التخلص من مصافحة TCP وحمل مفاوضات TLS (50-200 مللي ثانية لكل اتصال جديد).

---

الأسئلة المتداولة

ما هي حدود المعدلات التي يجب أن أضعها لواجهة برمجة التطبيقات العامة؟

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

كيف أتعامل مع ترقيم الصفحات عند تغير البيانات بين الصفحات؟

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

هل يجب علي استخدام REST أو GraphQL للأداء؟

يعد REST مع تحديد الحقل والتخزين المؤقت المناسب أسرع لنقاط النهاية البسيطة والمحددة جيدًا. يعمل GraphQL على التخلص من الجلب الزائد والجلب الناقص لمتطلبات البيانات المعقدة ولكنه يضيف حمل تحليل الاستعلام ويجعل التخزين المؤقت لـ HTTP أكثر صعوبة. استخدم REST لواجهات برمجة التطبيقات العامة ذات احتياجات التخزين المؤقت وGraphQL لواجهات برمجة التطبيقات الداخلية التي تخدم متطلبات بيانات الواجهة الأمامية المعقدة.

كيف يمكنني مراقبة أداء واجهة برمجة التطبيقات (API) في الإنتاج؟

تتبع أوقات الاستجابة P50 وP95 وP99 لكل نقطة نهاية. قم بتعيين التنبيهات على P95 لاختراق SLO الخاص بك (عادةً 200-500 مللي ثانية). استخدم التتبع الموزع لتقسيم الوقت المستغرق في قاعدة البيانات وذاكرة التخزين المؤقت والخدمات الخارجية ومنطق التطبيق. راجع دليلنا حول المراقبة وإمكانية الملاحظة للحصول على الإعداد التفصيلي.

---

ما هو التالي

ابدأ بتدقيق نقاط نهاية واجهة برمجة التطبيقات (API) الخاصة بك بحثًا عن ترقيم الصفحات المفقود، ونقاط النهاية العامة غير المحمية دون تحديد المعدل، والعمليات المتزامنة التي يجب أن تكون غير متزامنة. تعمل هذه التغييرات الثلاثة عادةً على تقليل أوقات استجابة P95 بنسبة 50-70% وتمنع حوادث الإنتاج الأكثر شيوعًا.

للحصول على منظور هندسة الأداء الكامل، راجع دليلنا الأساسي حول توسيع نطاق النظام الأساسي لأعمالك. بالنسبة لطبقة قاعدة البيانات التي تدعم واجهة برمجة التطبيقات الخاصة بك، اقرأ دليل تحسين الاستعلام.

تقوم ECOSIRE بإنشاء واجهات برمجة تطبيقات عالية الأداء لمنصات الأعمال على Odoo ERP والبنيات المخصصة. اتصل بنا لمراجعة أداء واجهة برمجة التطبيقات.

---

تم النشر بواسطة ECOSIRE — لمساعدة الشركات على التوسع باستخدام الحلول المدعومة بالذكاء الاصطناعي عبر Odoo ERP، وShopify eCommerce، وOpenClaw AI.