التنقل في مشهد بوابات API

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

يمكن اعتبار بوابات API بمثابة وكلاء عكسيين معززين يقدمون مرونة وقدرات أتمتة أكبر من الوكيل العكسي العادي. الأشهر منها مبنية على Envoy وHAProxy وNGINX.

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

القدرات الأساسية التي ينبغي أن نتوقعها:

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

تدفق نموذجي لحركة مرور الشبكة مع نشر API Gateway

نهج الواجهة الخلفية للواجهة الأمامية

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

استخدام بوابات API متعددة

في كثير من الأحيان، سترغب في الجمع بين القدرات التي توفرها السحابة (مثل جدار الحماية وتوجيه حركة المرور عالميًا) مع بنيتك التحتية الداخلية.

التطبيقات الشائعة التي يتم تشغيلها داخل Kubernetes:

• سفير،
• كونغ،
• Traefik،
• Spring Cloud Gateway.

تشمل موفري الخدمات السحابية الشائعين:

• Apigee،
• Azure API Management،
• Amazon API Gateway.

بعض الشركات التي كانت تطور أنظمة ESB دخلت أيضاً في سوق بوابات API. مثال على ESB، الذي يوفر ميزات API Gateway هو MuleSoft ESB.

احذر من ESBs التي تتنكر في هيئة بوابات API

بدلاً من الشرح بنفسي، دعنا نطّلع على توصيات خبراء الصناعة:

أهم عيب هو أنه عند تنفيذ بوابة API، فإنك تربط تلك الطبقة بالخدمات المصغّرة الداخلية. وقد يؤدي هذا الارتباط إلى صعوبات خطيرة في تطبيقك.

كليمنس فاستر، مهندس معماري في Azure Service Bus team

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

Thoughtworks، Technology Radar الإصدار 234

حدّد نمط البنية الذي ترغب في تنفيذه

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

تكوين نموذجي

نموذج لتكوين تعريفي لقاعدة التوجيه في بوابة Ambassador/Emissary مفتوحة المصدر:

kind: Service apiVersion: v1 metadata: name: your-api labels: app: your-api service: your-api annotations: getambassador.io/config: | --- apiVersion: ambassador/v1 kind: Mapping name: your-api_mapping prefix: /your-api/ service: your-api:8080 timeout_ms: 15000 spec: type: ClusterIP selector: app: your-api ports: - name: http port: 8080

سيقوم هذا التكوين ببساطة بالتقاط الطلب الذي يحمل البادئة «your-api»، وإزالتها، وإعادة توجيه الطلب إلى خدمة Your API Kubernetes.

تم قبول Emissary مؤخراً كواحد من مشاريع Cloud Native Computing Foundation. هناك الكثير من مشاريع Cloud Native المثيرة للاهتمام المدعومة من CNCF، أوصي بمتابعة موقعهم الإلكتروني: https://www.cncf.io/

بعض النصائح للتنفيذ الناجح

دعونا نوضح بعض النقاط حول كيفية استخدام بوابات API مع مراعاة المرونة وقابلية الصيانة:

• عادةً ما يكون هذا المكوّن نقطة فشل واحدة، وإذا أدخلت بعض العناصر الصغيرة من منطق الأعمال، فإنك تخاطر بكسر منصتك بأكملها، وليس فقط خدمة الواجهة الخلفية التي يتعلق التغيير المحدد.
• في البيئات الكبيرة حيث تتكون الواجهة الخلفية لديك من عشرات أو مئات الخدمات المصغرة، لا ينبغي أن يكون بمقدور الفرق التي تُجري تغييرات في نطاقها الخاص أن تُعطّل واجهات برمجة التطبيقات (APIs) الخاصة بفرق أخرى، وهو ما قد ينجم عن وضع أي منطق مخصص داخل البوابة (Gateway) الخاصة بنا.
• تتطلب بعض بوابات API الشائعة نشر مكونات متعددة، لذا ضع في اعتبارك تأثير ذلك على اتفاقية مستوى الخدمة (SLA) الخاصة بك.
• إذا كانت بوابة Kubernetes Ingress Gateway لديك تتطلب قاعدة بيانات لتعمل، فينبغي أن تصبح خبيرًا في أحمال العمل ذات الحالة ضمن مساحة Kubernetes.
• يمكنك التحقق من بيانات الاعتماد الواردة عند بوابة API، لكن هذا لا يعني أن خدمة الواجهة الخلفية لديك لا ينبغي أن تتحقق منها أيضاً، فطبّق دائماً سياسة الحد الأدنى من الثقة.
• اختر الحلول التي يمكن إدارتها من خلال التكوين التعريفي.
• يمكن لكل فريق إدارة إعداداته دون خطر تعطّل واجهات برمجة تطبيقات أخرى.
• ضع في اعتبارك سهولة التطوير المحلي، إذا كنت بحاجة إلى تشغيل API Gateway لاختبار الخدمة المصغرة محلياً، فاعتبر ذلك فشلاً.
• تقليل مساحة الفشل قدر الإمكان.
• اتبع نهج "نقاط النهاية الذكية، الأنابيب الغبية".

أوصي بشدة أيضًا بمحادثة فريق Netflix التقنية المتاحة على YouTube: إتقان الفوضى – دليل Netflix للخدمات المصغرة.

الأسئلة الشائعة