أنت الآن بصدد الاطّلاع على مستندات Apigee Edge.
انتقِل إلىمستندات Apigee X. info
تتيح Apigee Edge إمكانية ضبط عدد الطلبات المسموح بها لـ API Proxy لـ فترة زمنية معيّنة باستخدام سياسة الحصص.
نمط غير مستحسن
في حال إعادة استخدام سياسة الحصص، سيتم إنقاص عدّاد الحصص في كل مرة يتم فيها تنفيذ سياسة الحصص بغض النظر عن مكان استخدامها. أي في حال إعادة استخدام سياسة الحصص:
- ضمن التدفق نفسه أو تدفقات مختلفة من API Proxy
- في نقاط نهاية مختلفة من API Proxy
سيتم إنقاص عدّاد الحصص في كل مرة يتم فيها تنفيذه، وسنواجه أخطاء انتهاك الحصص قبل الوقت المتوقّع بكثير للفترة الزمنية المحدّدة.
لنستخدم المثال التالي لتوضيح طريقة عمل ذلك.
API Proxy
لنفترض أنّ لدينا API Proxy باسم "TestTargetServerQuota"، الذي يوجّه الزيارات إلى خادمَي وجهة مختلفَين استنادًا إلى مسار المورِد. ونريد حصر عدد الزيارات إلى واجهة برمجة التطبيقات بـ 10 طلبات في الدقيقة لكل من خادمَي الوجهة هذين. في ما يلي الجدول الذي يوضّح هذا السيناريو:
| مسار المورِد | خادم الوجهة | Quota |
|---|---|---|
/target-us |
target-US.somedomain.com |
10 طلبات في الدقيقة |
/target-eu |
target-EU.somedomain.com |
10 طلبات في الدقيقة |
سياسة الحصص
بما أنّ حصة الزيارات هي نفسها لكلا خادمَي الوجهة، نحدّد سياسة حصص واحدة باسم "Quota-Minute-Target-Server" كما هو موضّح أدناه:
<!-- /antipatterns/examples/1-8.xml --> <Quota name="Quota-Minute-Target-Server"> <Interval>1</Interval> <TimeUnit>minute</TimeUnit> <Distributed>true</Distributed> <Allow count="10"/> </Quota>
نقاط نهاية الوجهة
لنستخدم سياسة الحصص "Quota-Minute-Target-Server" في التدفق المسبق لنقطة نهاية الوجهة "Target-US":
<!-- /antipatterns/examples/1-9.xml --> <TargetEndpoint name="Target-US"> <PreFlow name="PreFlow"> <Request> <Step> <Name>Quota-Minute-Target-Server</Name> </Step> </Request> </PreFlow> <HTTPTargetConnection> <URL>http://target-us.somedomain.com</URL> </HTTPTargetConnection> </TargetEndpoint>
ونعيد استخدام سياسة الحصص نفسها "Quota-Minute-Target-Server" في التدفق المسبق لنقطة نهاية الوجهة الأخرى "Target-EU" أيضًا:
<!-- /antipatterns/examples/1-10.xml --> <TargetEndpoint name="Target-EU"> <PreFlow name="PreFlow"> <Request> <Step> <Name>Quota-Minute-Target-Server</Name> </Step> </Request> <Response/> </PreFlow> <HTTPTargetConnection> <URL>http://target-us.somedomain.com</URL> </HTTPTargetConnection> </TargetEndpoint>
نمط الزيارات الواردة
لنفترض أنّنا نتلقّى إجمالي 10 طلبات من واجهة برمجة التطبيقات لـ API Proxy هذا خلال أول 30 ثانية بالنمط التالي:
| مسار المورِد | /target-us |
/target-eu |
الكل |
|---|---|---|---|
| عدد الطلبات | 4 | 6 | 10 |
بعد ذلك بقليل، نتلقّى الطلب الحادي عشر من واجهة برمجة التطبيقات بمسار المورِد /target-us، لنفترض بعد 32 ثانية.
نتوقّع أن يتم تنفيذ الطلب بنجاح على افتراض أنّه لا يزال لدينا 6 طلبات من واجهة برمجة التطبيقات لنقطة نهاية الوجهة target-us وفقًا للحصة المسموح بها.
ومع ذلك، في الواقع، نتلقّى Quota violation error.
السبب: بما أنّنا نستخدم سياسة الحصص نفسها في كلتا نقطتَي نهاية الوجهة، يتم استخدام عدّاد حصص واحد لتتبُّع طلبات واجهة برمجة التطبيقات التي تصل إلى كلتا نقطتَي نهاية الوجهة. وبالتالي، نستنفد الحصة المحدّدة بـ 10 طلبات في الدقيقة بشكل جماعي بدلاً من أن يكون ذلك لنقطة نهاية الوجهة الفردية.
التأثير
يمكن أن يؤدي هذا النمط غير المستحسن إلى عدم تطابق أساسي في التوقّعات، ما يؤدي إلى الاعتقاد بأنّ حدود الحصص قد تم استنفادها قبل الوقت المتوقّع.
أفضل ممارسة
- استخدِم العنصرَين
<Class>أو<Identifier>لضمان الاحتفاظ بعدّادات متعدّدة وفريدة من خلال تحديد سياسة حصص واحدة. لنعدّل سياسة الحصص "Quota-Minute-Target-Server" التي أوضحناها للتو في القسم السابق باستخدام العنوانtarget_idكـ<Identifier>كما هو موضّح أدناه:<!-- /antipatterns/examples/1-11.xml --> <Quota name="Quota-Minute-Target-Server"> <Interval>1</Interval> <TimeUnit>minute</TimeUnit> <Allow count="10"/> <Identifier ref="request.header.target_id"/> <Distributed>true</Distributed> </Quota>
- سنواصل استخدام سياسة الحصص هذه في كلتا نقطتَي نهاية الوجهة "Target-US" و "Target-EU" كما كان من قبل.
- لنفترض الآن أنّه إذا كان العنوان
target_idيتضمّن القيمة "US"، يتم توجيه الطلبات إلى نقطة نهاية الوجهة "Target-US". - وبالمثل، إذا كان العنوان
target_idيتضمّن القيمة "EU"، يتم توجيه الطلبات إلى نقطة نهاية الوجهة "Target-EU". - حتى إذا استخدمنا سياسة الحصص نفسها في كلتا نقطتَي نهاية الوجهة، يتم الاحتفاظ بعدّادات حصص منفصلة
استنادًا إلى قيمة
<Identifier>. - لذلك، باستخدام العنصر
<Identifier>، يمكننا التأكّد من أنّ كل نقطة من نقاط نهاية الوجهة تحصل على الحصة المسموح بها البالغة 10 طلبات.
- استخدِم سياسة حصص منفصلة في كل تدفق أو نقطة نهاية وجهة أو API Proxy لضمان الحصول دائمًا على العدد المسموح به من طلبات واجهة برمجة التطبيقات. لنلقِ نظرة الآن على المثال نفسه المستخدَم في الـ
قسم أعلاه لنرى كيف يمكننا تحقيق الحصة المسموح بها البالغة 10 طلبات لكل نقطة من نقاط نهاية الوجهة.
- حدِّد سياسة حصص منفصلة، واحدة لكل من نقطتَي نهاية الوجهة "Target-US" و
"Target-EU"
سياسة الحصص لنقطة نهاية الوجهة "Target-US":
<!-- /antipatterns/examples/1-12.xml --> <Quota name="Quota-Minute-Target-Server-US"> <Interval>1</Interval> <TimeUnit>minute</TimeUnit> <Distributed>true</Distributed> <Allow count="10"/> </Quota>
سياسة الحصص لنقطة نهاية الوجهة "Target-EU":
<!-- /antipatterns/examples/1-13.xml --> <Quota name="Quota-Minute-Target-Server-EU"> <Interval>1</Interval> <TimeUnit>minute</TimeUnit> <Distributed>true</Distributed> <Allow count="10"/> </Quota>
- استخدِم سياسة الحصص المعنيّة في تعريف نقاط نهاية الوجهة كما هو موضّح أدناه:
نقطة نهاية الوجهة "Target-US":
<!-- /antipatterns/examples/1-14.xml --> <TargetEndpoint name="Target-US"> <PreFlow name="PreFlow"> <Request> <Step> <Name>Quota-Minute-Target-Server-US</Name> </Step> </Request> <Response/> </PreFlow> <HTTPTargetConnection> <URL>http://target-us.somedomain.com</URL> </HTTPTargetConnection> </TargetEndpoint>
نقطة نهاية الوجهة "Target-EU":
<!-- /antipatterns/examples/1-15.xml --> <TargetEndpoint name="Target-EU"> <PreFlow name="PreFlow"> <Request> <Step> <Name>Quota-Minute-Target-Server-EU</Name> </Step> </Request> <Response/> </PreFlow> <HTTPTargetConnection> <URL>http://target-eu.somedomain.com</URL> </HTTPTargetConnection> </TargetEndpoint>
- بما أنّنا نستخدم سياسة حصص منفصلة في نقطتَي نهاية الوجهة "Target-US" و "Target-EU"، سيتم الاحتفاظ بعدّاد منفصل. يضمن ذلك حصولنا على الحصة المسموح بها البالغة 10 طلبات من واجهة برمجة التطبيقات في الدقيقة لكل نقطة من نقاط نهاية الوجهة.
- حدِّد سياسة حصص منفصلة، واحدة لكل من نقطتَي نهاية الوجهة "Target-US" و
"Target-EU"
- استخدِم العنصرَين
<Class>أو<Identifier>لضمان الاحتفاظ بعدّادات متعدّدة وفريدة.