بوابات API والبروكسيات العكسية

بوابات API والبروكسيات العكسية

تضع كل منظومة واسعة النطاق طبقة من البنية التحتية أمام خدماتها الخلفية — قبل أن يصل أي طلب إلى خادم التطبيق. لهذه الطبقة تجليّان مترابطان لكنهما متمايزان: البروكسي العكسي وبوابة API. إن فهم ما يؤديه كل منهما، ولماذا يوجد، وأين تتداخل الحدود بينهما، أمرٌ لا غنى عنه لتصميم بنى إنتاجية حقيقية.

ما هو البروكسي العكسي؟

البروكسي العكسي خادمٌ يجلس بين العملاء الخارجيين وخادم خلفي واحد أو أكثر. يتحدث العملاء إلى البروكسي، فيحوّل البروكسي الطلبات إلى الخلف، ويعود الرد عبر البروكسي أيضاً. من منظور العميل لا يوجد سوى خادم واحد — البروكسي يُخفي كل شيء خلفه.

كلمة "عكسي" تُميّزه عن البروكسي الأمامي الذي يجلس أمام العملاء (كبروكسي الشبكة المؤسسية الذي يمر عبره كل حركة المرور الصادرة). البروكسي العكسي يجلس أمام الخوادم.

المسؤوليات الجوهرية للبروكسي العكسي:

• إنهاء TLS — فك تشفير HTTPS مرة واحدة عند الحافة؛ يمكن للحركة الداخلية البقاء على HTTP العادي في الشبكة الخاصة، مما يوفر قدرة المعالجة على كل خادم خلفي.
• موازنة الأحمال — توزيع الطلبات الواردة على مجموعة من النسخ الخلفية باستخدام استراتيجيات Round-Robin أو أقل اتصالاً أو IP-Hash أو الترجيح.
• التخزين المؤقت (Caching) — تخزين الأصول الثابتة أو ردود API مؤقتاً حتى لا تصل الطلبات المتكررة إلى الخلفية أصلاً.
• الضغط — ضغط الردود بـgzip أو Brotli في مكان واحد بدلاً من كل خلفية.
• تجميع الاتصالات — الحفاظ على اتصالات مستمرة مع الخوادم العلوية، مما يقلص عبء مصافحات TCP لكل استدعاء خلفي.
• DDoS / تحديد المعدل — إسقاط حركة المرور الاستغلالية أو تقليصها قبل وصولها إلى كود التطبيق.

أبرز البروكسيات العكسية: Nginx، HAProxy، Envoy، Caddy. نظائرها في السحابة: AWS ALB، GCP Cloud Load Balancing، Cloudflare.

ما هي بوابة API؟

بوابة API هي بروكسي عكسي متخصص مبني تحديداً لإدارة حركة مرور API. تؤدي كل ما يؤديه البروكسي العكسي، إضافة إلى مجموعة غنية من الاهتمامات الواعية بـAPI:

• المصادقة والتفويض — التحقق من صحة رموز JWT أو مفاتيح API أو OAuth قبل وصول الطلب إلى أي خدمة. تثق الخدمات بأن البوابة قد تحققت مسبقاً من هوية المتصل.
• تحديد المعدل والحصص — فرض حدود لكل عميل أو نقطة نهاية (مثلاً 1,000 طلب/دقيقة لكل مفتاح API). يمنع مستهلكاً صاخباً واحداً من تجويع الآخرين.
• تحويل الطلبات والردود — الترجمة بين إصدارات البروتوكول، وحذف الترويسات الداخلية، وحقن معرّفات الارتباط، وإعادة كتابة المسارات.
• التوجيه — توجيه /api/v1/users إلى خدمة المستخدمين و/api/v1/orders إلى خدمة الطلبات بناءً على المسار أو الترويسات أو معاملات الاستعلام.
• تجميع الطلبات (نمط BFF) — توزيع طلب عميل واحد على عدة خدمات علوية ودمج النتائج في رد واحد، مما يقلص رحلات الشبكة للتطبيقات المحمولة.
• الرصد والمراقبة — سجلات وصول مركزية ومقاييس الكمون وترويسات التتبع الموزع المحقونة في كل طلب.
• قطع الدائرة وإعادة المحاولة — التوقف التلقائي عن التوجيه إلى خدمة علوية متدهورة وإعادة المحاولة على الأعطال العابرة مع تراجع.

أبرز بوابات API: Kong (مفتوحة المصدر، إضافات Lua/Go)، AWS API Gateway، Azure API Management، Apigee، Traefik، Envoy + Istio (نهج الشبكة الخدمية).

البنية المعمارية: البوابة أمام الخدمات المصغرة

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

إنهاء TLS بالتفصيل

من أكثر ميزات البروكسي العكسي قيمة عالمياً إنهاء TLS. إليك ما يوفره:

• لم يعد كل خادم خلفي بحاجة إلى شهادة TLS. تُدار الشهادات في مكان واحد.
• تكلفة المعالجة لمصافحة TLS — التي يمكن أن تصل مع RSA-2048 إلى 10–50 مللي ثانية — تُدفع مرة واحدة عند البروكسي، ولا تتضاعف عبر كل نسخة خدمة.
• تبقى حركة المرور الداخلية على شبكة خاصة موثوقة، فيتجنب النظام عبء التشفير حيث لا يستوجبه نموذج التهديد. (في البيئات الخاضعة للتنظيم أو Zero-Trust، تُعاد عملية التشفير بعد البروكسي — يُسمى ذلك TLS passthrough أو mTLS bridging).
• تجديد الشهادات يحدث عند طبقة البروكسي دون المساس بنشر التطبيقات.

استراتيجيات تحديد المعدل

تُطبّق بوابات API تحديد المعدل لحماية الخدمات وضمان الاستخدام العادل. الخوارزميات الشائعة:

• دلو الرمز (Token Bucket) — دلو بسعة N يتجدد بمعدل R رمز/ثانية. يكلّف كل طلب رمزاً واحداً. يسمح بانفجارات محكومة تصل إلى N. تستخدمه AWS API Gateway ومعظم مزودي السحابة.
• الدلو المسرّب (Leaky Bucket) — تملأ الطلبات قائمة انتظار تستنزف بمعدل ثابت؛ تُسقط الطلبات الزائدة. ينتج ناتجاً سلساً جداً لكنه لا يستوعب الانفجارات.
• عداد النافذة الثابتة — حساب الطلبات لكل نافذة زمنية (مثلاً 1,000/دقيقة). بسيط، لكن انفجاراً عند الحدود يتيح فعلياً ضعف الحد.
• سجل النافذة المنزلقة — دقيق، يحتفظ بسجل طوابع زمنية لكل عميل. دقيق لكن ثقيل على الذاكرة عند الحجم الكبير.

نمط BFF (Backend for Frontend)

Backend for Frontend هو نوع متخصص من بوابة API حيث تُنشئ نسخة بوابة منفصلة لكل نوع عميل — واحدة لتطبيق الجوال، وأخرى لتطبيق الويب، وأخرى للشركاء الخارجيين. تجمّع كل BFF البيانات وتُشكّلها تحديداً لاحتياجات ذلك المستهلك.

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

أشاع هذا النمط Netflix وSoundCloud حين اكتشفا أن API "عاماً" واحداً أجبر كل عميل على رحلات متعددة وتحليل بيانات أكثر بكثير مما يحتاجه.

المقايضات وأنماط الأعطال

البوابة تجريد قوي لكن بتكاليف حقيقية:

• نقطة فشل وحيدة — إن توقفت البوابة، فقد كل عميل الوصول إلى كل خدمة. الحل: نسخ متعددة من البوابة خلف موازن أحمال مع فحوصات صحة مكثفة.
• زمن استجابة إضافي — كل طلب يمر بعقدة إضافية. بوابة مضبوطة جيداً تضيف ~1–5 مللي ثانية. بوابة مُهيأة بشكل خاطئ تُجري فحوصات قاعدة بيانات متزامنة لكل مصادقة يمكنها إضافة 50+ مللي ثانية.
• تعقيد تشغيلي — تتراكم المنطق الأفقي في البوابة بمرور الوقت وقد تصبح عنق زجاجة للفرق. اعتمد عملية إعداد تعريفية تخضع لمراجعة كودية مبكراً.
• تضخيم التوزيع — طلب عميل واحد يُطلق استدعاءات علوية متعددة. إن كانت خدمة علوية بطيئة (تأخر ذيلي)، يُعاق الرد المدموج بأكمله. استخدم الطلبات المتحوطة أو مهلات لكل خدمة علوية للتحكم في ذلك.

أرقام حقيقية

لمعايرة نموذجك الذهني:

• Nginx على VM واحدة بأربعة أنوية يمكنه إعادة توجيه ~50,000 طلب/ثانية بعبء أقل من 5 مللي ثانية عند النسبة المئوية 95.
• Kong (مبني على Nginx + Lua) يضيف ~1–3 مللي ثانية لكل إضافة (مصادقة، تحديد معدل) لكل طلب. عند 10 إضافات يصبح ذلك 10–30 مللي ثانية — خطط لعدد إضافاتك وفقاً لذلك.
• AWS API Gateway له حد افتراضي 10,000 طلب/ثانية على مستوى الحساب ويتقاضى رسوماً لكل مليون طلب (~3.50$). عند الإنتاجية العالية جداً، الانتقال إلى ALB مع بوابة ذاتية الإدارة يكون في الغالب أوفر.
• تشغّل Twitter طبقة بوابة API مخصصة (تُعرف داخلياً بـ"TFE — Twitter Front End") تتولى المصادقة والتوجيه والمراقبة لـ~300,000 طلب في الثانية في الذروة.

تجميع الصورة

نقطة الدخول الجاهزة للإنتاج لنظام خدمات مصغرة تبدو عادةً هكذا:

1. طبقة CDN / الحافة (Cloudflare، Fastly) — تخزّن الأصول الثابتة مؤقتاً، تُنهي TLS أقرب إلى المستخدم، تمتص هجمات DDoS الحجمية.
2. بوابة API (Kong، AWS API GW، Envoy مخصص) — مصادقة، تحديد معدل، توجيه، رصد، إعادة محاولة.
3. موازن الأحمال — إن كانت البوابة نفسها مُجمّعة، يوزع موازن الطبقة الرابعة الحمل بين نسخ البوابة.
4. الخدمات العلوية — تتولى كل خدمة منطق مجالها فحسب، واثقةً أن البوابة قد تحققت من الهوية وفرضت الحصص مسبقاً.

البروكسي العكسي وبوابة API ليسا تسهيلات اختيارية — بل هما مستوى التحكم لسطح API الخاص بك. الصواب فيهما يعني أن تظل خدماتك بسيطة، وموقفك الأمني متسقاً، ومراقبتك مُمركزة منذ اليوم الأول.