معالجة الطلبات المجمعة باستخدام API Gateway
April 27, 2023
معالجة الطلبات المجمعة هي تقنية قوية تُستخدم في تطوير الويب لتحسين أداء واجهات برمجة التطبيقات (APIs). تتيح للمطورين تجميع عدة طلبات API في دورة طلب/استجابة HTTP واحدة. بمعنى آخر، يمكن تحويل طلب API واحد من العميل إلى عدة طلبات API إلى مجموعة من الخوادم الخلفية، ويتم تجميع الاستجابات في استجابة واحدة يتم إرسالها إلى العميل. يمكن أن يقلل ذلك بشكل كبير من عدد الرحلات بين العميل والخادم.
في هذه المقالة، سنستكشف كيفية تنفيذ معالجة الطلبات المجمعة في Apache APISIX ونلقي نظرة على بعض حالات الاستخدام التي يمكن أن تكون مفيدة فيها.
تشبه هذه التقنية نمط تكوين API الذي يُطبق على نطاق واسع في هندسة الخدمات المصغرة.
لماذا نستخدم معالجة الطلبات المجمعة؟
عندما يرسل العميل عدة طلبات API إلى الخادم، يتطلب كل طلب دورة طلب/استجابة HTTP منفصلة. يمكن أن يؤدي ذلك إلى زيادة زمن الوصول، وتقليل الأداء، وزيادة الحمل على الخادم. من خلال تجميع عدة طلبات في طلب مجمع واحد، يمكن تقليل عدد دورات طلب/استجابة HTTP، مما يؤدي إلى تحسين الأداء وتقليل زمن الوصول.
يمكن أن تكون معالجة الطلبات المجمعة مفيدة بشكل خاص في السيناريوهات التي تحتاج فيها إلى استرداد أو تحديث عدة سجلات في معاملة واحدة، مثل:
- استرداد عدة سجلات من قاعدة البيانات
- تحديث عدة سجلات في قاعدة البيانات
- تنفيذ عدة طلبات API لإكمال مهمة
أمثلة واقعية لمعالجة الطلبات المجمعة
المثال الأول:
لنفترض أن لديك تطبيق وسائط اجتماعية يعرض موجز المستخدم، والذي يتضمن مشاركات من أصدقائه والصفحات التي يتابعها. لملء هذا الموجز، تحتاج إلى إجراء عدة طلبات API لاسترداد البيانات اللازمة، مثل:
- استرداد قائمة أصدقاء المستخدم والصفحات التي يتابعها.
- لكل صديق أو صفحة، استرداد مشاركاتهم الأخيرة.
في النهج التقليدي، ستقوم بإجراء كل من هذه الطلبات API بشكل منفصل. أولاً، تسترد قائمة أصدقاء المستخدم، وفي الطلب الثاني، تحصل على المشاركات الأخيرة لكل صديق. يمكن أن يؤدي ذلك إلى زيادة زمن الوصول، خاصة عندما يكون لدى المستخدم عدد كبير من الأصدقاء ويتبع العديد من الصفحات.
المثال الثاني:
مثال آخر، لديك تطبيق جوال يعرض قائمة منتجات للمستخدمين لتصفحها. لملء هذه القائمة، تحتاج إلى إجراء عدة طلبات API لاسترداد بيانات المنتج من خادم بعيد، مثل:
- استرداد قائمة معرفات المنتجات.
- لكل معرف منتج، استرداد تفاصيل المنتج (الاسم، الوصف، الصورة، إلخ).
المثال الثالث:
تخيل أن لديك تطبيق ويب لإدارة المؤتمرات حيث يوجد عدة متحدثين في النظام وتريد عرض جلسات المتحدث والمواضيع ذات الصلة على صفحة ويب واحدة. يحتوي خدمة Conference API الخلفية على نقطتي نهاية مختلفتين /speaker/{speakerId}/sessions
و /speaker/{speakerId}/topics
لعرض هذه المعلومات. لعرض كل من الجلسات والمواضيع التي تخص متحدثًا واحدًا، يمكنك إرسال طلبين من التطبيق الأمامي، وهو ليس حلاً مثاليًا. بدلاً من ذلك، يمكنك استخدام بوابة API لتجميع كل هذه الطلبات في طلب HTTP واحد، كما سيتم شرحه في القسم التالي.
معالجة الطلبات المجمعة مع بوابة Apache APISIX API
لتنفيذ معالجة الطلبات المجمعة في APISIX، يمكنك استخدام المكون الإضافي batch-requests. يسمح لك هذا المكون الإضافي بتحديد مجموعة من طلبات API في حمولة طلب HTTP POST
واحدة. يمكن أن يكون لكل طلب طريقة HTTP الخاصة به، ومسار URL، ومجموعة من الرؤوس، وحمولة. انظر إلى أمر طلب curl أدناه للمثال الثالث (طلبات Conference API):
curl -i http://{API_GATEWAY_HOST_ADDRESS}/speaker -X POST -d \
'{
"pipeline": [
{
"method": "GET",
"path": "/speaker/1/topics"
},
{
"method": "GET",
"path": "/speaker/1/sessions"
}
]
}'
عند استلام طلب مجمع بواسطة APISIX، سيقوم المكون الإضافي batch-requests بتحليل الحمولة وتنفيذ كل طلب في المجموعة بشكل متوازي. سيقوم المكون الإضافي أيضًا بتجميع الاستجابات من كل طلب وإعادتها في استجابة HTTP واحدة إلى العميل. انظر إلى قسم العرض التوضيحي التالي لمعرفة كيفية تحقيق ذلك خطوة بخطوة.
عرض توضيحي للمكون الإضافي لطلبات المجمعة
قبل أن تتمكن من استخدام المكون الإضافي batch-requests، ستحتاج إلى تثبيت Apache APISIX.
المتطلبات الأساسية
- Docker يُستخدم لتثبيت etcd وAPISIX في حاويات.
- curl يُستخدم لإرسال الطلبات إلى واجهة برمجة تطبيقات إدارة APISIX. يمكنك أيضًا استخدام أدوات سهلة مثل Postman للتفاعل مع الواجهة البرمجية.
يمكن تثبيت APISIX وبدء تشغيله بسهولة باستخدام البرنامج النصي التالي للبدء السريع:
curl -sL <https://run.api7.ai/apisix/quickstart> | sh
تكوين خدمة الخلفية (upstream)
ستحتاج إلى تكوين خدمة الخلفية لـ Conference API التي تريد توجيه الطلبات إليها. يمكن القيام بذلك عن طريق إضافة خادم upstream في Apache APISIX من خلال واجهة برمجة تطبيقات الإدارة.
curl http://127.0.0.1:9180/apisix/admin/upstreams/1 -X PUT -d '
{
"name": "Conferences API upstream",
"desc": "Register Conferences API as the upstream",
"type": "roundrobin",
"scheme": "https",
"nodes": {
"conferenceapi.azurewebsites.net:443": 1
}
}'
إنشاء مسار لمعالجة API المجمعة
نحتاج إلى إنشاء مسار جديد يعترض الطلبات إلى /speaker
ويعرض نقطة نهاية عامة افتراضية لمعالجة المجموعات باستخدام المكون الإضافي [public-api](https://apisix.apache.org/docs/apisix/plugins/public-api/)
.
curl http://127.0.0.1:9180/apisix/admin/routes/a -X PUT -d '
{
"uri": "/speaker",
"plugins": {
"public-api": {
"uri": "/apisix/batch-requests"
}
}
}'
إنشاء مسار لنقاط نهاية مواضيع وجلسات المتحدث
بعد ذلك، نقوم بإنشاء مسار آخر لنقاط نهاية مواضيع وجلسات المتحدث (/speaker/*/topics
و /speaker/*/topics
التي تطابق المسارات) بحيث يتم توجيه الطلبات الفردية المستخرجة من بوابة API من الطلبات المجمعة لاسترداد مواضيع أو جلسات المتحدث إلى نقاط نهاية Conference API المسؤولة، ونشير إلى خدمة upstream الموجودة.
curl http://127.0.0.1:9180/apisix/admin/routes/b -X PUT -d '
{
"methods": ["GET"],
"uris": ["/speaker/*/topics","/speaker/*/sessions"],
"plugins": {
"proxy-rewrite":{
"host":"conferenceapi.azurewebsites.net"
}
},
"upstream_id":"1"
}'
قد تلاحظ أننا نستخدم مكونًا إضافيًا آخر proxy-rewrite ونحدد بشكل ضمني عنوان المضيف لـ Conference API. وإلا، يمكن أن تقوم بوابة API بتحويل DNS وطلب Conference API باستخدام عنوان IP الخاص بها.
اختبار معالجة الطلبات المجمعة
إليك مثال عن كيفية استخدام المكون الإضافي batch-requests في APISIX:
curl -i http://127.0.0.1:9080/speaker -X POST -d \
'{
"pipeline": [
{
"method": "GET",
"path": "/speaker/1/topics"
},
{
"method": "GET",
"path": "/speaker/1/sessions"
}
]
}'
في هذا المثال، تم تعريف المسار لنقطة النهاية /speaker
، والتي تدعم معالجة الطلبات المجمعة عبر المكون الإضافي batch-requests. تم تكوين المكون الإضافي بمجموعة من طلبين، كل منهما يسترد سجل متحدث حسب المعرف مع المواضيع والجلسات. إذا قمت بتشغيل هذا الأمر، ستحصل على استجابة مجمعة من بوابة API:
[
{
"body":"{\r\n \"collection\": {\r\n \"version\": \"1.0\",\r\n \"links\": [],\r\n \"items\": [\r\n {\r\n \"href\": \"https://conferenceapi.azurewebsites.net/topic/8\",\r\n \"data\": [\r\n {\r\n \"name\": \"Title\",\r\n \"value\": \"Microsoft\"\r\n }\r\n ],\r\n \"links\": [\r\n {\r\n \"rel\": \"http://tavis.net/rels/sessions\",\r\n \"href\": \"https://conferenceapi.azurewebsites.net/topic/8/sessions\"\r\n }\r\n ]\r\n },\r\n {\r\n \"href\": \"https://conferenceapi.azurewebsites.net/topic/10\",\r\n \"data\": [\r\n {\r\n \"name\": \"Title\",\r\n \"value\": \"Mobile\"\r\n }\r\n ],\r\n \"links\": [\r\n {\r\n \"rel\": \"http://tavis.net/rels/sessions\",\r\n \"href\": \"https://conferenceapi.azurewebsites.net/topic/10/sessions\"\r\n }\r\n ]\r\n }\r\n ],\r\n \"queries\": [],\r\n \"template\": {\r\n \"data\": []\r\n }\r\n }\r\n}",
"status":200,
"headers":{
"Expires":"-1",
"Connection":"keep-alive",
"Pragma":"no-cache",
"Content-Length":"953",
"Server":"APISIX/3.2.0",
"Content-Type":"application/vnd.collection+json",
"X-AspNet-Version":"4.0.30319",
"Cache-Control":"no-cache",
"X-Powered-By":"ASP.NET"
},
"reason":"OK"
},
{
"body":"{\r\n \"collection\": {\r\n \"version\": \"1.0\",\r\n \"links\": [],\r\n \"items\": [\r\n {\r\n \"href\": \"https://conferenceapi.azurewebsites.net/session/206\",\r\n \"data\": [\r\n {\r\n \"name\": \"Title\",\r\n \"value\": \"\\r\\n\\t\\t\\tjQuery Mobile and ASP.NET MVC\\r\\n\\t\\t\"\r\n },\r\n {\r\n \"name\": \"Timeslot\",\r\n \"value\": \"05 December 2013 09:00 - 10:00\"\r\n },\r\n {\r\n \"name\": \"Speaker\",\r\n \"value\": \"Scott Allen\"\r\n }\r\n ],\r\n \"links\": [\r\n {\r\n \"rel\": \"http://tavis.net/rels/speaker\",\r\n \"href\": \"https://conferenceapi.azurewebsites.net/speaker/16\"\r\n },\r\n {\r\n \"rel\": \"http://tavis.net/rels/topics\",\r\n \"href\": \"https://conferenceapi.azurewebsites.net/session/206/topics\"\r\n }\r\n ]\r\n }\r\n ],\r\n \"queries\": [],\r\n \"template\": {\r\n \"data\": []\r\n }\r\n }\r\n}",
"status":200,
"headers":{
"Expires":"-1",
"Connection":"keep-alive",
"Pragma":"no-cache",
"Content-Length":"961",
"Server":"APISIX/3.2.0",
"Content-Type":"application/vnd.collection+json",
"X-AspNet-Version":"4.0.30319",
"Cache-Control":"no-cache",
"X-Powered-By":"ASP.NET"
},
"reason":"OK"
}
]
يتم تحديد الحجم الأقصى للطلب المجمع بواسطة بوابة API. يمكنك التحقق من وثائق بوابة API للاطلاع على الحدود الحالية وتكوين مهلة الطلب.
النقاط الرئيسية
- يمكن أن تكون معالجة الطلبات المجمعة مع بوابة API تقنية مفيدة لتحسين أداء واجهة برمجة التطبيقات الخاصة بك.
- يوفر Apache APISIX مكونًا إضافيًا يسمى
batch-requests
يسمح للمطورين بتنفيذ معالجة الطلبات المجمعة بسهولة.
الخطوات التالية
مع بوابة API، يمكن أيضًا توفير شكل من أشكال التجميع المخصص في بيانات الاستجابة للمستخدمين. يمكنك استخدام المكون الإضافي serverless-function لتنفيذ كود مخصص ودمج الاستجابة من خدمات الخلفية وإعادتها إلى مستهلك API في هيكل مختلف.