نمط بوابة API

نمط بوابة API

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

ما تفعله البوابة

بوابة API هي وكيل عكسي (reverse proxy) يمتلك وعيًا بطبقة التطبيق. كل طلب خارجي يدخل عبر البوابة؛ وتقرر البوابة كيفية توجيه هذا الطلب وتحويله وتأمينه وإعادة توجيهه إلى الخدمة (أو الخدمات) المناسبة في المنبع، ثم تجمّع الاستجابة وتعيدها إلى المُستدعي.

المسؤوليات الأساسية للبوابة تشمل:

• التوجيه: تعيين مسار أو مضيف وارد إلى عنوان URL الصحيح للخدمة المنبعية.
• المصادقة والتفويض: التحقق من الرموز (JWT، OAuth 2.0) مرة واحدة عند الحافة حتى لا تكرر الخدمات الفردية هذا العمل.
• إنهاء TLS: قبول HTTPS خارجيًا وإعادة التوجيه عبر HTTP داخليًا لتبسيط شهادات الخدمات.
• تحديد المعدل والتقنين: حماية الخدمات الخلفية من ارتفاعات حركة المرور وإساءة الاستخدام.
• تحويل الطلبات والاستجابات: إضافة الترويسات أو حذفها وإعادة كتابة المسارات والترجمة بين البروتوكولات.
• قابلية المراقبة: مركزة سجلات الوصول وحقن التتبع الموزع وجمع المقاييس.
• التجميع (Backend for Frontend): توزيع استدعاء خارجي واحد على عدة خدمات داخلية ودمج النتائج.

بدون بوابة مقابل مع بوابة

تخيّل تطبيق هاتف يعرض صفحة ملف المستخدم الشخصي. يحتاج إلى بيانات من ثلاث خدمات: user-service وorder-service وnotification-service.

بدون بوابة يجب على عميل الهاتف:

1. اكتشاف user-service والاتصال به مباشرةً.
2. اكتشاف order-service والاتصال به مباشرةً.
3. اكتشاف notification-service والاتصال به مباشرةً.
4. التعامل مع المصادقة بشكل منفصل لكل خدمة.
5. دمج الاستجابات الثلاث بنفسه.

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

مع بوابة يُجري عميل الهاتف استدعاءً واحدًا إلى api.example.com/profile. تتفرع البوابة داخليًا إلى الخدمات الثلاث وتدمج البيانات وتعيد حمولة واحدة نظيفة. طولوجيا الخدمة غير مرئية للعميل.

الانعكاسات الأمنية

تصبح البوابة الحدود الأمنية لنظامك. لهذا عواقب مهمة:

• التحقق من الرمز عند الحافة: تحقق من JWTs مرة واحدة في سلسلة فلاتر البوابة. يمكن للخدمات المنبعية الوثوق برأس موجَّه (مثل X-User-Id أو X-Roles) بدلًا من إعادة تحليل التوقيعات والتحقق منها في كل استدعاء. يوفر هذا وحدة المعالجة المركزية ويبسّط الخدمات — لكنه يعني ضرورة الوثوق بالشبكة الداخلية. لا تكشف أبدًا الخدمات المنبعية مباشرةً للإنترنت.
• تقليل سطح الهجوم: البوابة وحدها موجهة للعموم. يمكن تقييد منافذ جميع الخدمات المنبعية بجدار حماية لقبول حركة المرور فقط من شبكة البوابة الفرعية.
• تطبيق السياسة المركزية: يمكن تطبيق ترويسات CORS وHSTS وسياسات أمان المحتوى والتحقق من صحة المدخلات باستمرار في مكان واحد بدلًا من تنفيذها (وربما نسيانها) في كل خدمة.

مقايضات الأنظمة الموزعة

تُدخل البوابة تبعية متزامنة في مسار الاستدعاء. قبل قبول هذه المقايضة، افهم ما تأخذه على عاتقك:

• نقطة فشل واحدة: إذا توقفت البوابة توقفت جميع حركة المرور الخارجية. خفّف هذا بنسخ متعددة من البوابة خلف موازن تحميل مع فحوصات صحية شاملة.
• تأخير إضافي: كل طلب يضيف قفزة شبكة واحدة ووقت معالجة البوابة. عمليًا يكون هذا من 1 إلى 5 مللي ثانية لبوابة تفاعلية مضبوطة جيدًا وهو مقبول. حالات استخدام التجميع يمكنها فعليًا تقليل إجمالي زمن استجابة العميل عن طريق موازاة الاستدعاءات المنبعية.
• اختناق قابلية التوسع: يجب أن تتوسع البوابة أفقيًا جنبًا إلى جنب مع خدماتك. التنفيذ غير المانع والتفاعلي (كـ Spring Cloud Gateway المبني على Reactor Netty) يتعامل مع اتصالات متزامنة كثيرة على مجموعة خيوط صغيرة — أفضل بكثير من نموذج خيط لكل طلب.
• اقتران النشر: تغييرات تكوين المسار تتطلب إعادة نشر البوابة (أو تحديث التكوين الديناميكي). في البيئات عالية التغيير يقلل التوجيه الديناميكي من سجل الخدمات هذا الاقتران.

طولوجيات البوابة الشائعة

لا توجد طولوجيا صحيحة واحدة. الشكل الصحيح يعتمد على مستهلكيك:

• بوابة واحدة: بوابة واحدة لجميع المستهلكين. سهلة التشغيل؛ تخاطر بأن تصبح اختناقًا لتنسيق الفرق المتعددة.
• Backend for Frontend (BFF): بوابة واحدة لكل نوع عميل (BFF للهاتف، BFF للويب، بوابة API للشركاء). تمتلك كل BFF منطق التجميع والتحويل الخاص بمستهلكها. يمكن للفرق تطويرها بشكل مستقل.
• بوابات متعددة الطبقات: بوابة حافة خارجية تتعامل مع إنهاء TLS والحماية من هجمات DDoS؛ بوابة داخلية تتعامل مع التوجيه والمصادقة. شائعة في المنظمات الكبيرة التي لديها فريق منصة مخصص يدير طبقة الحافة.

كيف تتلاءم البوابة مع اكتشاف الخدمات والتكوين

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

• تُحلل البوابة lb://order-service عبر Eureka (أو Consul أو Kubernetes DNS) إلى مجموعة من النسخ السليمة.
• يتم تقديم تكوين البوابة نفسه (المسارات والفلاتر وحدود تقنين المعدل) من خادم التكوين حتى يمكن تحديثه دون نشر كود جديد.
• عندما تُنشر نسخة جديدة من خدمة منبعية يتغير إدخال السجل فقط — مسار البوابة يبقى كما هو.

هذه هي البنية التي ستبنيها في الدرس التاسع، حيث يجتمع Eureka وخادم التكوين وSpring Cloud Gateway معًا. الدرس القادم يُقدّم Spring Cloud Gateway تحديدًا — نموذج الفلاتر وشروط التوجيه وكيفية تكوينه في Spring Boot 3.

الخلاصة

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