إدارة واجهات API · دليل

تحديد معدل طلبات API: كيف تختارون الحدود والحصص، وأين تناسب Kong

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

نُشر في 8 دقائق قراءة

راجعوا حدود واجهاتكم معنا قارنوا بين الطرق

الخلاصة للإدارة

  • ما هو: قاعدة على البوابة ترفض الطلبات التي تتجاوز معدلًا متفقًا عليه، لكل مستهلك ولكل مسار.
  • لماذا يهم: يُبقي الخدمات المشتركة متاحة، ويجعل الاستخدام العادل في اتفاقيات الشركاء قابلًا للتطبيق، ويضع سقفًا للإنفاق على الخدمات المدفوعة.
  • ما لا يفعله: لا يوقف وحده هجومًا مصممًا، ولا يعالج بطء الخدمة، لكنه يحدّ من الضرر.
  • أين تناسب Kong: تحديد المعدل إضافة على البوابة، والتحكم الأدق في إصدار Enterprise، وحدود الرموز لحركة نماذج اللغة في Kong AI Gateway.

نظرة سريعة

تحديد معدل طلبات API في نظرة سريعة
السؤالالجواب
ما الذي يضبطهعدد الطلبات في الثانية أو الدقيقة أو الساعة أو اليوم، لكل مستهلك أو مسار أو مستخدم
ماذا يرى المتصل عند الرفضغالبًا رمز الحالة HTTP 429 Too Many Requests، ومعه كثيرًا ترويسة Retry-After
حد المعدل أم الحصةحد المعدل يحمي السعة خلال ثوانٍ أو دقائق، والحصة مقدار مسموح به خلال يوم أو شهر
لحركة نماذج اللغةتُحسب الرموز (tokens) أو التكلفة، لا عدد الطلبات
إضافات KongRate Limiting، وRate Limiting Advanced في Enterprise، وAI Rate Limiting Advanced لحركة نماذج اللغة
من إنتركيحدود مبنية على الاستخدام الفعلي، معرّفة على هيئة شيفرة، مع المراقبة والدعم من الرياض

المشكلة التي يحلها تحديد معدل طلبات API، بلغة واضحة

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

اقرأ المزيد

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

لماذا يهم ضبط حركة الواجهات للجهات في المملكة

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

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

طرق تحديد المعدل: النافذة الثابتة والنافذة المتحركة ودلو الرموز

تجيب كل طريقة عن السؤال نفسه: هل يمر هذا الطلب الآن؟ لكن لكل منها موازنة مختلفة بين البساطة، والعدالة عند حدود المدة، والسماح بالدفعات القصيرة.

الطرق الشائعة لتحديد معدل طلبات API وما لكل منها وعليها
الطريقةكيف تحسبميزتهاما يجب الانتباه إليه
النافذة الثابتة (Fixed window)تعدّ الطلبات في مدد ثابتة، مثل كل دقيقة بحسب الساعة، ثم تبدأ العد من جديد مع المدة التاليةسهلة الفهم، قليلة الكلفة في الحساب، ويسهل شرحها للشركاءيستطيع المتصل إرسال حصته كاملة في آخر الدقيقة ثم حصة أخرى في أول الدقيقة التالية
النافذة المتحركة (Sliding window)تعدّ الطلبات خلال المدة الأخيرة محسوبة من اللحظة الحالية، فتتحرك النافذة مع الوقتتخفف أثر حدود المدة في النافذة الثابتة، وأعدل تحت الحمل المستمرعمل أكثر قليلًا لكل طلب، ويختلف سلوكها الدقيق من منتج إلى آخر
دلو الرموز (Token bucket)دلو يمتلئ بمعدل ثابت، وكل طلب يأخذ رمزًا، وإذا فرغ الدلو رُفضت الطلباتيسمح بدفعات قصيرة بقدر سعة الدلو مع الحفاظ على المعدل المتوسطتحتاج سعة الدلو ومعدل امتلائه إلى ضبط وشرح كليهما
حد التزامن (Concurrency limit)يحدد عدد الطلبات الجارية في وقت واحد من المتصل نفسهيحمي الخدمات البطيئة حين يأتي الضرر من طلبات قليلة طويلةلا يحد من الطلبات السريعة، فيُستخدم إلى جانب حد المعدل لا بدلًا منه

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

على ماذا تُحسب الحدود: المستهلك والمسار وحد المعدل لكل مستخدم والحصص

عدالة الحد من عدالة الهوية التي يُحسب عليها. والحساب بعنوان IP خيار ضعيف إذا اعتُمد وحده، فكثير من موظفي الشركة الواحدة يتشاركون عنوانًا واحدًا، بينما يستطيع المسيء التنقل بين عناوين كثيرة.

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

إدارة الحصص: المقدار اليومي والشهري

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

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

روابط ذات صلةصفحة أمن واجهات APIبوابة المطورين

تحديد المعدل بالرموز لحركة نماذج اللغة

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

وتوثّق Kong سياسة AI Rate Limiting Advanced على أنها تحسب الرموز أو التكلفة لا عدد الطلبات، مع حدود لكل مستهلك أو مجموعة مستهلكين أو نموذج أو مزوّد، حتى لا تستهلك تجربة فريق واحد ميزانية فريق آخر. وتضع Kong عليها عبارة "AI License Required" ضمن عرض AI Gateway Enterprise. وتشرح صفحة بوابة الذكاء الاصطناعي من Kong طريقة حساب التكلفة وبقية السياسات، ويتناول دليل بوابة نماذج اللغة التصميم الأوسع.

روابط ذات صلةصفحة بوابة الذكاء الاصطناعي من Kongدليل بوابة نماذج اللغة

قائمة تحقق قبل ضبط حدود معدل الطلبات

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

أين تناسب Kong في تحديد معدل الطلبات، وأين لا تناسب

Kong هي البوابة التي تطبّقها إنتركي. وتحديد المعدل في Kong إضافة على البوابة، تُعرَّف مع بقية الإعدادات.

خيارات Kong لتحديد معدل طلبات API وما يتطلبه كل منها
الحاجةفي Kongما ينبغي معرفته
حدود أساسية لكل مستهلكإضافة Rate Limitingغير مصنّفة Enterprise فقط
حدود مشتركة بين عقد البوابةRate Limiting مع استراتيجية clusterتتطلب النشر التقليدي الذي تتصل فيه العقد بقاعدة بيانات
تحكم أدق في النوافذ والحدودRate Limiting Advancedمتاحة في Enterprise فقط
سقف لحجم الطلبRequest Size Limitingغير مصنّفة Enterprise فقط
حدود الرموز والتكلفة لطلبات نماذج اللغةAI Rate Limiting Advanced في Kong AI Gatewayجزء من عرض AI Gateway Enterprise
حدود منطق العمل، مثل عدد التحويلات لكل عميل في اليومليست من عمل البوابةمكانها الخدمة نفسها، فهي التي تعرف العميل والعملية

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

ما الذي يحدد التكلفة والمدة

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

ويُسعَّر ترخيص Kong، حين تحتاجون إلى Rate Limiting Advanced أو سياسات AI Gateway، بشروط Kong، في بند مستقل عن عمل إنتركي.

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

كيف تساعدكم إنتركي في ضبط حدود معدل الطلبات

  1. القياس.

    قراءة الحركة الحالية لكل مستهلك ومسار من سجلات البوابة أو من منصة المراقبة لديكم.

  2. كتابة السياسة.

    الحدود والدفعات والحصص وسلوك الرفض لكل نوع من المستهلكين، بالاتفاق مع مالكي الواجهات.

  3. الإعدادات على هيئة شيفرة.

    إضافات معرّفة بأداة decK، تُراجع وتُختبر قبل الإنتاج.

  4. التطبيق بالتدريج.

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

  5. الدعم.

    دعم من الرياض بالعربية والإنجليزية، أو تشغيل بنطاق خدمات مُدارة مكتوب.

أسئلة يطرحها العملاء عن تحديد معدل الطلبات

ما الفرق بين تحديد معدل الطلبات وضبط الحركة (throttling)؟

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

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

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

كيف نحدد الحد المناسب لكل شريك؟

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

هل نحتاج إلى Kong Enterprise لتحديد المعدل في المملكة؟

لا للحدود الأساسية، فإضافة Rate Limiting في Kong غير مصنّفة Enterprise فقط. أما Rate Limiting Advanced وحدود الرموز في AI Gateway فهي كذلك. ويُسعَّر الترخيص بشروط Kong بعد مراجعة متطلباتكم مقابل قائمة إضافات Kong الحالية.

هل يمكن أن تبقى عدّادات الحدود وسجلاتها داخل السعودية؟

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

كم يستغرق تطبيق الحدود دون أن تتعطل أنظمة المستهلكين؟

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

التالي

اقرأ أيضًا

بوابة API للمؤسسات في المملكة أمن واجهات API: ما تفرضه البوابة وما لا تستطيعه بوابة الذكاء الاصطناعي من Kong إدارة واجهات البرمجة (API) في المملكة

الخطوة التالية

راجعوا حدود واجهاتكم معنا

أخبرونا بالواجهات التي تتيحونها، ومن يستهلكها، والبوابة التي تشغّلونها اليوم، وأين سببت الحدود أو غيابها مشكلات. وسنقترح حدودًا لكل مستهلك ومسار، وخطوات تطبيقها دون تعطيل أحد.

خانة إلزامية

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

أو مباشرةً

+966-11-2180999 [email protected]

أبراج التعاونية، البرج الشمالي، الطابق السابع، طريق الملك فهد، العليا، ص.ب. ٥٦٨٣٥، الرياض ١١٥٦٤، المملكة العربية السعودية

أو قارنوا بين الطرق

نشرته إنتركي. آخر تحديث . إنتركي مسجلة في الرياض بالسجل التجاري رقم 1010156897.