ما هو API Gateway، ولماذا يعتبر ضروريًا؟

مقدمة إلى واجهات برمجة التطبيقات (APIs)

ما هي واجهة برمجة التطبيقات (API)؟ API هي طريقة قياسية لتبادل البيانات بين التطبيقات والأنظمة المختلفة. تتبنى العديد من فرق التطوير نهج API-first حيث يتم التركيز على التكرار في تصميم وتنفيذ واختبار وتأمين ونشر واستكشاف الأخطاء وتحليل APIs، وهو ما يُعرف بإدارة دورة حياة API الكاملة (APIM).

قبل ظهور APIs، لم تكن هناك طريقة قياسية لتبادل البيانات. كانت البرامج الحاسوبية تتواصل مع بعضها البعض باستخدام مجموعة متنوعة من البروتوكولات مثل FTP، FTPS، SFTP، HTTPS، إلخ. أدى عدم وجود معايير إلى تكاليف تطوير عالية ومخاطر أمنية خفية في العديد من الجوانب: التحكم في الأذونات، إدارة البيانات، الحد من المعدل، التدقيق، إلخ. هذا هو "برج بابل" في عالم الحاسوب. لبناء منتج معقد بما فيه الكفاية، يجب علينا حل المشكلات الناتجة عن أنظمة تم تطويرها بلغات مختلفة ومخططات تخزين بيانات مختلفة.

لقد نجح ظهور API في حل مشكلة "برج بابل". يحتاج المطورون فقط إلى التركيز على APIs التي تعرضها الأنظمة الأخرى وليس هناك حاجة لفهم تفاصيل التنفيذ الأساسية.

الاتصال ونقل البيانات بين أجهزة العميل والخوادم للتطبيقات المحمولة، الألعاب عبر الإنترنت، بث الفيديو المباشر، المؤتمرات عن بُعد، وأجهزة IoT كلها لا يمكن أن تعمل بدون APIs. تلعب APIs دورًا مهمًا في تواصلها.

لماذا نستخدم بوابة API؟

بوابة API هي مكون أساسي في إدارة دورة حياة API الكاملة. وهي مسؤولة عن تكوين API، الإصدار، التراجع عن الإصدار، الأمان، وموازنة الحمل في بيئة الإنتاج. بالإضافة إلى ذلك، تعتبر بوابة API مدخل كل حركة مرور العميل، حيث تقوم بتوجيه طلب API من العميل إلى الخدمة الصحيحة للمعالجة ثم إعادة البيانات المرتجعة إلى الطالب الأصلي مع ضمان سلامة وموثوقية وكفاءة العملية بأكملها.

عندما لا يكون هناك الكثير من APIs في البداية، تكون بوابة API عادةً مكونًا افتراضيًا يتم دمجه مع خادم الويب والخدمات العلوية. يتم تنفيذ وظائف بسيطة مثل التوجيه، الإعادة، الوكيل العكسي، وموازنة الحمل بواسطة Apache، NGINX، وبعض المكونات الأخرى؛ بينما تعتمد وظائف أخرى مثل المصادقة والحد من المعدل على الخدمات العلوية.

لماذا تحتاج إلى بوابة API؟

ومع ذلك، مع زيادة عدد APIs، وجد المطورون "الكسالى" مشكلة خطيرة. في أجزاء مختلفة من الخدمات العلوية، يتم تكرار نفس المصادقة، الحد من المعدل، التسجيل، وبعض الوظائف الأخرى مرارًا وتكرارًا. هذا ليس فقط إهدارًا للموارد؛ بل هو أيضًا كابوس لإدارة الكود. عندما يتم تعديل أو ترقية جزء من الكود، يجب تحديث الكود في أماكن أخرى. كيف نحل هذه المشكلة؟ وجد المطورون الأذكياء حلًا سريعًا: استخراج الوظائف المشتركة ووضعها في مكون واحد. نقوم بسحب الكود غير المرتبط بمنطق الأعمال من الخدمات العلوية، وتعزيز مكونات Apache وNGINX. هذا هو تطور بوابة API من الجيل الأول.

اتجاه تطور بوابة API هو تضمين أكبر عدد ممكن من الوظائف غير المرتبطة بالأعمال. من أجل تسريع تكرار المنتج، يطالب مطورو الواجهة الأمامية والخلفية بالمزيد والمزيد من بوابات API، ليس فقط محدودة بالوظائف التقليدية مثل التوجيه، الإعادة، الوكيل العكسي، وموازنة الحمل، ولكن أيضًا يطالبون بوظائف للرصد مثل gRPC وGraphQL.

دور بوابات API

لجعل بوابة API أكثر مرونة وكفاءة، قام مطورو بوابات API بالعديد من الابتكارات على البنية التحتية، مثل:

• وظائف الإضافات. مع تضمين المزيد والمزيد من الوظائف على بوابة API، كيف نفصل كل وظيفة لتسهيل التطوير؟ ستكون آلية الإضافات الشبيهة بـ Lego الحل المثالي. تستخدم بوابات API الرئيسية جميعها الإضافات. في Apache APISIX، تُسمى "الإضافات". في Envoy، تُسمى "المرشحات". تحرر الإضافات مطوري البوابة من تفاصيل التنفيذ، وتحتاج إلى موارد تطوير أقل لتنفيذ وظائف جديدة.
• فصل مستوى البيانات ومستوى التحكم. في الجيل الأول من بوابة API، يتم تنفيذ مستوى البيانات ومستوى التحكم في نفس عملية الحاسوب. هذا أسهل للمستخدمين للنشر والاستخدام ولكنه يخلق مخاطر أمنية كبيرة. يوفر مستوى البيانات الخدمات مباشرة للعالم الخارجي. إذا اخترق المتسللون مستوى البيانات من الخارج، يمكنهم الحصول على أذونات التحكم وبيانات مستوى التحكم (مثل شهادات SSL)، مما قد يتسبب في أضرار مدمرة. لذلك، تقوم معظم بوابات API مفتوحة المصدر الآن بنشر DP وCP بشكل منفصل واستخدام قواعد البيانات العلائقية أو etcd لإدارة ومزامنة التكوينات.

بأخذ Apache APISIX كمثال، يوضح الرسم البياني التالي الابتكارات المذكورة أعلاه:

التحديات من الحوسبة السحابية الأصلية

أكبر تغيير تكنولوجي في مجال تكنولوجيا المعلومات خلال العقد الماضي كان الحوسبة السحابية الأصلية. فتح Docker، الذي ولد في عام 2013، الستار على الحوسبة السحابية الأصلية. منذ ذلك الحين، تم استبدال الأجهزة المادية والآلات الافتراضية بالحاويات، وتم استبدال البنى الأحادية بـالخدمات المصغرة. ومع ذلك، فإن الحوسبة السحابية الأصلية ليست ثورة تكنولوجية بسيطة. القوة الدافعة وراءها تأتي من التطور السريع والمنافسة الشرسة لمنتجات الإنترنت. ولدت التقنيات المرتبطة بالحوسبة السحابية الأصلية في الوقت المناسب وسرعان ما أصبحت شائعة وحلت محل العديد من البنى والحلول التقنية السابقة. على وجه التحديد، تأتي تحديات بوابة API في الحوسبة السحابية الأصلية بشكل رئيسي من الجوانب التالية:

من البنية الأحادية إلى الخدمات المصغرة

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

ومع ذلك، فإن تطوير الخدمات المصغرة يجلب أيضًا بعض الآثار الجانبية، مثل:

• زاد عدد APIs والخدمات المصغرة من العشرات إلى الآلاف أو حتى عشرات الآلاف.
• كيف نحدد بسرعة أي API تسبب الخطأ؟
• كيف نضمن أمان API؟
• كيف نحقق كسر الدائرة وتخفيض الخدمة؟

لا يمكن لبوابة API حل مشكلات الأمان، الرصد، والإصدار التجريبي بمفردها. تحتاج إلى التعاون مع العديد من المشاريع مفتوحة المصدر وخدمات SaaS مثل Prometheus، Zipkin، Skywalking، Datadog، Okta، إلخ، لتقديم حلول أفضل للشركات.

الإدارة الديناميكية وإدارة المجموعات

التحدي الأول يأتي من النظام البيئي، بينما يأتي الثاني من التكنولوجيا.

الديناميكية

أصبحت الحاويات وKubernetes شائعة لدرجة أن الديناميكية أصبحت ميزة قياسية لجميع مكونات الحوسبة السحابية الأصلية الأساسية. في بيئة Kubernetes، يتم إنشاء الحاويات وتدميرها باستمرار، وأصبح التوسع المرن ضرورة وليس خيارًا.

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

هناك أيضًا تحديات تقنية مرتبطة بالتوسع المرن للحاويات:

• تغيير عناوين IP ومنافذ الخدمات العلوية بشكل متكرر.
• تحديثات متكررة لقوائم السماح والمنع لعناوين IP.
• الكشف عن الحالات الشاذة والتعامل مع صحة الخدمة.
• الإصدارات المنتظمة لـ APIs.
• التوقيت المناسب لتسجيل الخدمة واكتشافها.
• تجديد شهادات SSL الساخن والدوران التلقائي.

في قلب معالجة هذه التحديات التقنية هي الديناميكية.

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

إدارة المجموعات

النقطة الألم التقنية الثانية هي إدارة المجموعات.

WPS، شركة برمجيات مكتبية SaaS في الصين، والتي توفر برمجيات مثل Microsoft office 365. لديها مئات الآلات المادية التي تعمل على Apache APISIX، ما يقرب من 10,000 وحدة معالجة مركزية تعالج طلبات API من العملاء، وتعالج عشرات المليارات من APIs يوميًا.

في بيئة بوابة API فائقة الكبر هذه، من المستحيل للمطورين تعديل تكوين كل بوابة API واحدة تلو الأخرى ثم إعادة تحميلها. بدلاً من ذلك، يريدون وحدة تحكم متكاملة للتحكم في المجموعة بأكملها. لسوء الحظ، عندما ولدت بوابات API من الجيل الأول، لم يكن هناك مثل هذا الحجم الكبير من الحالات، لذلك لم يفكر مطورو بوابات الجيل الأول في احتياجات إدارة المجموعات.

بوابة API من الجيل التالي

التحديات ونقاط الألم المذكورة أعلاه أدت تدريجيًا إلى ظهور بوابات API من الجيل التالي.

ميزات بوابة API من الجيل التالي

على عكس بوابات API من الجيل الأول، فإن المجتمع المفتوح المصدر هو القوة الدافعة الرئيسية لتطوير بوابات API من الجيل التالي في عصر الحوسبة السحابية الأصلية. مع قوة المجتمع والعديد من المساهمين المفتوحي المصدر، أصبحت هذه البوابات لديها الفرصة لتشكيل دورة تكرار وتطور إيجابية:

• القدرة على جمع احتياجات ونقاط ألم المطورين والمستخدمين بسرعة أكبر.
• محاولة حل هذه المشكلات في المشاريع المفتوحة المصدر.
• تصبح المشاريع المفتوحة المصدر أسهل في الاستخدام، مما يجذب المزيد من المطورين.

في هذه العملية، تخترق بوابة API من الجيل التالي موقع موازنة الحمل والوكيل العكسي للبوابات التقليدية وتتحمل المزيد من المسؤوليات، مثل اتصال حركة المرور، الجدولة، التصفية، التحليل، تحويل البروتوكول، الحوكمة، والتكامل (انظر أدناه).

بوابة API تدعم التطوير الثانوي بتكلفة أقل

في الوقت نفسه، أصبح السماح للمطورين بإجراء تطوير مخصص بتكلفة أقل أيضًا من أبرز ميزات بوابة API من الجيل التالي. التكامل هو أحد الوظائف الأساسية لبوابة API. بالنسبة للجهة السفلية، فهو تحليل البروتوكول وتحويله، بما في ذلك GraphQL، gRPC، Dubbo، إلخ؛ بالنسبة للجهة العلوية، فهو يتكامل مع Okta، Keycloak، Datadog، وPrometheus لخدمات المصادقة والرصد وخدمات الشهادات الداخلية للشركة، التسجيل، التدقيق، وغيرها.

لا يمكن أن تغطي بوابة API جميع مكونات عملية التكامل. لذلك، من المحتم أن يقوم المطورون بإجراء تطوير مخصص من خلال الإضافات لتلبية احتياجات أعمالهم الخاصة.

توفر بوابات API المختلفة لغات برمجة وطرق تطوير مختلفة للتطوير المخصص. على سبيل المثال، يمكن لكل من Apache APISIX وKong استخدام Lua لكتابة الإضافات الأصلية، بينما يستخدم Envoy C++ لكتابة الإضافات الأصلية. في الوقت نفسه، يمكن لـ Apache APISIX أيضًا استخدام Go، Python، Node.js، Java، وWasm لتطوير الإضافات. يستخدم جميع المطورين تقريبًا إحدى لغات البرمجة الرئيسية هذه.

المصدر المفتوح والتطوير المخصص السهل هما أهم ميزات بوابة API من الجيل التالي. يوفران المزيد من الخيارات للمطورين. في الوقت نفسه، يمكن للمطورين استخدام بوابة API بثقة في بيئة متعددة السحابات أو هجينة، دون القلق بشأن التقييد من قبل مزودي الخدمات السحابية.

مثال: بوابة API لحركة مرور الجمعة السوداء

بعد ذلك، دعونا نشرح ما تفعله بوابة API بمثال ملموس.

في يوم الجمعة السوداء، تقوم شركات التجارة الإلكترونية بالعديد من العروض الترويجية، ويكون حجم طلبات API خلال هذه الفترة عشرات المرات أعلى من المعتاد. أولاً، دعونا نلقي نظرة على ما ستكون عليه البنية التقنية إذا لم تكن هناك بوابة API:

كما ترى من الصورة أعلاه، يتم تكرار وظائف المصادقة والتسجيل في خدمات الطلب والدفع. تتكون خدمة التجارة الإلكترونية بشكل عام من آلاف الخدمات المختلفة. في هذا الوقت، سيتم تكرار الكثير من الأكواد والإجراءات.

الشكل التالي هو مخطط البنية بعد إضافة بوابة API:

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

عندما يبدأ العرض الترويجي، يصب ملايين طلبات API من العملاء في بوابة API، وتحتاج الخدمة الخلفية إلى إجراء توسع مرن سريع. لحماية الأعمال الحرجة من التأثر بحركة المرور المفاجئة، نحتاج إلى تحديد الزواحف الضارة على بوابة API وتنفيذ التقييد، تخفيض الخدمة، وكسر الدائرة.

يمكننا أيضًا إيقاف بعض الخدمات مؤقتًا، مثل تقييم المنتجات، استعلامات الشحن، إلخ. ومع ذلك، يجب ألا تفشل الأعمال الأساسية مثل معلومات المخزون، الشراء، والدفع. لذلك، نحتاج إلى إدارة خدمة الحاويات من خلال K8s وإنشاء المزيد من نسخ الخدمة للحفاظ على عملها بشكل صحيح. في هذا الوقت، تحتاج بوابة API إلى توجيه طلب API من العميل إلى نسخة الخدمة الجديدة وإزالة الخدمة المعطلة تلقائيًا، كما هو موضح في الشكل التالي:

الخلاصة

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

يمكن لبوابة API التعامل ليس فقط مع حركة مرور API، ولكن أيضًا مع حركة المرور من Kubernetes Ingress وشبكة الخدمة، مما يقلل من منحنى تعلم المطورين ويساعد الشركات على إدارة حركة المرور بشكل متكامل.

اتصل بنا لمعرفة المزيد عن Apache APISIX، API7 Enterprise Edition، ومنتجات API7 Cloud.