يا جماعة الخير، خلوني أحكيلكم قصة صارت معي ومع فريقي قبل كم سنة. كنا وقتها متحمسين جداً لمفهوم الخدمات المصغرة (Microservices)، وقررنا نطبقه في مشروع كبير لتطبيق تجارة إلكترونية. قلنا لحالنا “خلص، بدنا نفكفك المونوليث (Monolith) ونعمل كل إشي خدمة لحالها: خدمة للمستخدمين، خدمة للمنتجات، خدمة للطلبات، وهلم جرا”.
في البداية، كان الوضع “لوز”، وكل إشي تمام. كل مطور ماسك خدمة وشغال عليها. بس لما بلشنا نربط الواجهات الأمامية (Frontend) – تطبيق الموبايل والموقع الإلكتروني – مع هاي الخدمات، بلشت المصايب تبيّن. المطور تبع الموبايل صار بده يعرف عنوان الـ IP والـ port تبع كل خدمة. ولما نغيّر إشي بسيط في خدمة المنتجات، كان لازم نبلّغ مطور الموبايل ومطور الموقع عشان يعدّلوا الكود عندهم. الوضع صار فوضى، والله يا إخوان كانت ليالي نقضيها بس نحل مشاكل “الاتصال ما بزبط!” أو “ليش هاي الـ endpoint بترجع 404؟”. صرت حاسس حالي مش مبرمج، صرت حاسس حالي موظف “سنترال” بوصل مكالمات بين الخدمات والواجهات. كانت شغلة بترفع الضغط!
في ليلة من الليالي، وأنا قاعد براجع الكود الساعة 2 الفجر وبشرب فنجان القهوة الخامس، قلت لحالي: “لأ، مش هيك الشغل. لازم يكون في حل أحسن، حل يلملم هاي الفوضى”. ومن هنا بدأت رحلتنا مع المنقذ: الـ API Gateway.
ما هي الفوضى التي كنا نعيشها (قبل الـ API Gateway)؟
لكي تفهموا حجم المشكلة، دعوني ألخص لكم التحديات التي واجهتنا عند التعامل مع الخدمات المصغرة مباشرة من الواجهات الأمامية:
- تعقيد العميل (Client Complexity): كان على كل عميل (تطبيق الموبايل، الموقع) أن يكون على دراية ببنية النظام الخلفي بالكامل. كان عليه معرفة عنوان كل خدمة من عشرات الخدمات، وكيفية التعامل معها.
- كثرة الطلبات (Chatty I/O): لعرض صفحة واحدة بسيطة مثل “ملفي الشخصي”، كان تطبيق الموباGيل يحتاج لإرسال عدة طلبات: طلب لجلب معلومات المستخدم، وطلب لجلب آخر طلباته، وطلب لجلب المنتجات المفضلة لديه. هذا يؤدي إلى بطء في الأداء وتجربة مستخدم سيئة.
- صعوبة إدارة الاهتمامات المشتركة (Cross-Cutting Concerns): كل خدمة كانت تحتاج إلى منطق للتحقق من هوية المستخدم (Authentication)، وتسجيل الطلبات (Logging)، وتحديد معدل الطلبات (Rate Limiting). هذا أدى إلى تكرار الكود في كل مكان، ويا ويلي من صيانة الكود المكرر!
- مشاكل أمنية: عرض جميع خدماتنا مباشرة على الإنترنت كان بمثابة ترك أبواب بيتنا الخلفية مفتوحة على مصراعيها. أي ثغرة في أي خدمة يمكن استغلالها بسهولة.
- تطور صعب: لو أردنا تحديث خدمة وتغيير نقطة النهاية (Endpoint) الخاصة بها، أو حتى دمج خدمتين في واحدة، كان ذلك يعني كسر التطبيقات العميلة. كنا مقيدين.
المنقذ: بوابة الواجهة البرمجية (API Gateway)
ببساطة شديدة، الـ API Gateway هي عبارة عن خادم (Server) يعمل كنقطة دخول وحيدة ومركزية لجميع الطلبات القادمة من العملاء. هي الواجهة الأمامية لكل خدماتنا المصغرة. زي ما بنقول، هي “أبو العُرّيف” اللي بستقبل كل الضيوف عند باب العمارة، وبوجه كل ضيف للشقة الصحيحة بدون ما الضيف يعرف تفاصيل العمارة من جوا.
العميل (Client) يرسل طلبًا واحدًا إلى البوابة، والبوابة بدورها، وبناءً على قواعد محددة، تقوم بتوجيه هذا الطلب إلى الخدمة المصغرة المناسبة (أو عدة خدمات)، ثم تجمع النتائج وترجعها للعميل في استجابة واحدة.
نصيحة من أبو عمر: لا تفكر في الـ API Gateway على أنها مجرد “بروكسي” أو موجه (Proxy/Router). إنها طبقة ذكية يمكنها القيام بأكثر من مجرد التوجيه، كما سنرى.
كيف أنقذتنا الـ API Gateway عملياً؟
بمجرد تطبيقنا لنمط الـ API Gateway، شعرنا بالفرق فوراً. إليكم الفوائد التي لمسناها على أرض الواقع:
1. التجريد والتبسيط (Decoupling)
أول وأهم فائدة. لم يعد تطبيق الموبايل أو الموقع بحاجة لمعرفة أي شيء عن خدماتنا الداخلية. كل ما يعرفه هو عنوان واحد: api.our-awesome-app.com. خلف هذا العنوان، يمكننا إضافة خدمات، حذف خدمات، تقسيم خدمة إلى ثلاث خدمات، أو دمج عشر خدمات في واحدة، كل ذلك دون أن يشعر العميل بأي تغيير. لقد حررتنا من قيود الماضي.
2. مركزية الاهتمامات المشتركة (Centralizing Cross-Cutting Concerns)
بدلاً من كتابة كود التحقق من الهوية (Authentication) في كل خدمة، قمنا بتطبيقه مرة واحدة فقط في الـ API Gateway. الآن، أي طلب يصل إلى البوابة يتم التحقق منه أولاً. إذا كان المستخدم مصرحًا له بالدخول، تسمح له البوابة بالمرور إلى الخدمة المطلوبة. وإذا لم يكن كذلك، يتم رفض الطلب عند الباب. هذا ينطبق على:
- التحقق من الهوية والصلاحيات (Authentication & Authorization): التأكد من أن المستخدم هو من يدعي وأنه يمتلك الصلاحيات الكافية.
- تسجيل النشاطات (Logging): تسجيل جميع الطلبات والاستجابات في مكان واحد مركزي لتحليلها ومراقبتها.
- تحديد معدل الطلبات (Rate Limiting): حماية خدماتنا من هجمات الحرمان من الخدمة (DoS) أو من الاستخدام المفرط.
- التخزين المؤقت (Caching): يمكن للبوابة تخزين الاستجابات للطلبات المتكررة (مثل قائمة المنتجات الأكثر مبيعاً) وإعادتها مباشرة دون إزعاج الخدمات الخلفية، مما يحسن الأداء بشكل كبير.
3. تجميع الطلبات (Request Aggregation)
تذكرون مشكلة كثرة الطلبات؟ الـ API Gateway حلتها ببراعة. قمنا بإنشاء نقطة نهاية جديدة في البوابة اسمها /api/v1/mobile/dashboard. عندما يطلب تطبيق الموبايل هذه النقطة، تقوم البوابة بما يلي:
- ترسل طلبًا إلى خدمة المستخدمين لجلب معلومات المستخدم.
- ترسل طلبًا إلى خدمة الطلبات لجلب آخر 3 طلبات.
- ترسل طلبًا إلى خدمة المنتجات لجلب العروض المخصصة للمستخدم.
- تنتظر جميع الاستجابات، ثم تجمعها في كائن JSON واحد مرتب، وترسله كتجاوب واحد لتطبيق الموبايل.
هذا قلل عدد الرحلات ذهابًا وإيابًا (Roundtrips) بين العميل والخادم بشكل كبير، مما أدى إلى تحميل أسرع للبيانات وتجربة مستخدم أفضل بكثير.
4. التوجيه الذكي (Smart Routing)
البوابة ليست مجرد موجه غبي. يمكنها اتخاذ قرارات توجيه ذكية. على سبيل المثال، يمكننا إعدادها لتوجيه 95% من الزيارات إلى الإصدار المستقر من خدمة المنتجات (v1)، وتوجيه 5% فقط إلى الإصدار التجريبي الجديد (v2) لاختباره على عينة صغيرة من المستخدمين (وهو ما يعرف بـ Canary Release).
هذا مثال بسيط على ملف إعدادات (YAML) لبوابة مثل Kong أو Tyk يوضح كيفية التوجيه:
# مثال توضيحي لملف إعدادات بوابة API
routes:
- name: user-service-route
paths:
- /api/users
upstream_url: http://user-service:8080
- name: product-service-route
paths:
- /api/products
upstream_url: http://product-service:8081
- name: order-service-route
paths:
- /api/orders
upstream_url: http://order-service:8082
بهذه البساطة، أي طلب يبدأ بـ /api/users سيتم توجيهه داخلياً إلى user-service.
نصائح من كيس أبو عمر
بعد هذه التجربة، خرجت ببعض الدروس والنصائح التي أحب أن أشاركها معكم:
- لا تجعل البوابة “مونوليث” جديد: أكبر خطأ يمكن أن تقع فيه هو وضع الكثير من منطق العمل (Business Logic) داخل البوابة. حافظ على البوابة خفيفة ومخصصة للمهام التقنية (التوجيه، الأمان، …إلخ). إذا بدأت البوابة تفهم “ما معنى طلب شراء”، فأنت تسير في الطريق الخطأ. زي ما بنقول “ما بدنا نطلع من حفرة لنوقع بدحديرة”.
- اختر البوابة المناسبة لك: هناك العديد من الخيارات المتاحة في السوق. هناك حلول سحابية مُدارة مثل AWS API Gateway و Azure API Management، وهي ممتازة للبدء بسرعة. وهناك حلول مفتوحة المصدر يمكنك استضافتها بنفسك مثل Kong, Tyk, و Ocelot (لمطوري .NET). اختر ما يناسب خبرة فريقك وميزانيتك.
- راقب البوابة جيداً: بما أن البوابة هي نقطة الدخول الوحيدة، فهي أيضاً نقطة فشل وحيدة (Single Point of Failure). لذلك، يجب مراقبة أدائها (Latency, Error Rate) عن كثب والتأكد من أنها قابلة للتوسع (Scalable) لتتحمل الضغط.
- ابدأ ببساطة: لست بحاجة إلى تطبيق كل ميزات البوابة من اليوم الأول. يمكنك البدء بمجرد استخدامها كموجه عكسي (Reverse Proxy)، ثم إضافة الميزات الأخرى (مثل التحقق من الهوية والتخزين المؤقت) تدريجياً حسب الحاجة.
الخلاصة… والزبدة
الانتقال إلى معمارية الخدمات المصغرة كان قرارًا صائبًا، لكنه لم يكتمل ولم يصبح ناجحًا إلا بعد أن وضعنا أمامه “بوابة الواجهة البرمجية”. الـ API Gateway ليست مجرد أداة تقنية، بل هي تغيير في طريقة التفكير، فهي تفرض النظام، وتفصل بين العوالم (العالم الخارجي الفوضوي والعالم الداخلي المنظم)، وتسمح لفريقك بالتركيز على ما هو مهم: بناء خدمات رائعة.
إذا كنت تبدأ مشروعًا يعتمد على الخدمات المصغرة، أو إذا كنت تعاني بالفعل من فوضى إدارتها، فأنصحك بشدة أن تجعل الـ API Gateway هي خطوتك التالية. صدقني، ستشكرني لاحقاً. 😉
