ما هي سياسات API Gateway؟

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

ما هي سياسات بوابات API

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

1. التحقق مما إذا كان الطلب قانونيًا. هل هو من قائمة المستخدمين الممنوعين من الوصول؟
2. التحقق مما إذا كان الطلب مصادقًا عليه وما إذا كان المحتوى الذي يتم الوصول إليه مصرحًا به.
3. التحقق مما إذا كان الطلب يثير قيودًا محددة، مثل حدود المعدل.
4. التحقق إلى أي خدمة علوية سيتم إعادة توجيه الطلب.

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

على سبيل المثال، لنأخذ بوابة API Apache APISIX، هناك نوعان من معلومات التكوين في APISIX: ملف التكوين لبدء تشغيل البوابة، مثل config.yaml، هذا الملف يحدد بعض التكوينات الضرورية لبدء تشغيل البوابة بشكل طبيعي. بالإضافة إلى ذلك، يمكن للمديرين إنشاء قواعد وتكوينات مختلفة بشكل ديناميكي من خلال Admin API أثناء التشغيل، مثل Route، Consumer، Plugin، إلخ. سياسات بوابة API هي القواعد والتكوينات المختلفة التي يتم إنشاؤها بشكل ديناميكي من قبل المدير من خلال Admin API.

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

سياسة المصادقة والتفويض

المصادقة يمكنها تأكيد هوية المتصل بـ API، والتفويض يقيد المتصل للوصول فقط إلى الموارد ضمن الصلاحية.

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

المصادقة الأساسية

سياسة المصادقة الأساسية للوصول هي أبسط تقنية للتحكم في الوصول. بشكل عام، يحمل وكيل HTTP الخاص بالمستخدم رأس طلب للمصادقة عند إرسال الطلب، والذي يكون عادةً: Authorization: Basic <credentials>، وتشمل credentials معرف المستخدم وكلمة المرور المطلوبة لمصادقة المستخدم، مفصولة بـ :. هذه الطريقة لا تتطلب إعدادات معقدة مثل صفحات تسجيل الدخول وملفات تعريف الارتباط. يتم المصادقة بناءً على معلومات بسيطة في رأس الطلب، عادةً اسم المستخدم وكلمة المرور، وهي بسيطة في التكوين والاستخدام.

مثال على طلب cURL مع المصادقة الأساسية هو كما يلي، مع username و password:

curl -i -u 'username:password' http://127.0.0.1:8080/hello

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

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

مصادقة المفتاح

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

خذ على سبيل المثال مكون key-auth في APISIX. يحتاج المكون إلى إنشاء Consumer مع قيمة مفتاح فريدة من خلال Admin API:

curl http://127.0.0.1:9180/apisix/admin/consumers \
-H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "username": "jack",
    "plugins": {
        "key-auth": {
            "key": "jack-key"
        }
    }
}'

يقوم هذا الطلب بإنشاء Consumer باسم jack مع قيمة المفتاح jack-key.

عند تمكين المكون في المسار، تحتاج إلى تكوين موقع واسم الحقل للمفتاح في الطلب. التكوين الافتراضي للموقع هو header، واسم الحقل هو apikey، لذلك الكود الصحيح لطلب هذا المسار هو:

curl -i http://127.0.0.1:8080/hello -H 'apikey: jack-key'

بمجرد استلام APISIX لهذا الطلب، سيقوم APISIX بتحليل المفتاح ومطابقة Consumer jack من جميع المفاتيح المكونة. لذلك ستعرف البوابة أن الطلب تم إرساله بواسطة jack. يمكن الحكم على أنه طلب غير قانوني إذا لم يتم العثور على مفتاح مطابق.

JSON Web Token

JSON Web Token (JWT) هو معيار مفتوح يعرف طريقة لنقل المعلومات بشكل آمن بين الأطراف في شكل كائنات json. يمكن لسياسة JWT الجمع بين المصادقة والتفويض. بعد تفويض المستخدم، سيتم نقل رمز JWT إلى المستخدم، وسيحمل المتصل هذا الرمز في جميع الطلبات اللاحقة لضمان أن الطلب مصرح به.

في بوابة API، يمكن إضافة JWT للمصادقة إلى البوابة من خلال سياسة JWT. لذلك، يمكننا فصل منطق المصادقة عن كود الأعمال، ويمكن للمطورين التركيز أكثر على تنفيذ منطق الأعمال. خذ على سبيل المثال مكون jwt-auth في APISIX. يجب تمكين المكون وتكوينه في Consumer مع مفتاحه الفريد، المفاتيح العامة والخاصة للتشفير، خوارزمية التشفير، وقت انتهاء صلاحية الرمز، إلخ. في نفس الوقت، تحتاج إلى تمكين هذا المكون في المسار وتكوين البوابة لقراءة موقع وحقول الرمز، مثل header، query، cookie، إلخ. سيضيف هذا المكون API إلى بوابة API لإصدار الرموز. قبل إرسال الطلب، تحتاج إلى طلب API الذي يصدر الرمز. يجب حمل الرمز في الموقع المحدد وفقًا لمعلومات التكوين عند إرسال الطلب. بعد وصول الطلب إلى البوابة، ستقرأ البوابة الرمز من الموقع المحدد للطلب وفقًا لمعلومات التكوين وتتحقق من صحة الرمز. يمكن إعادة توجيه الطلب إلى الخدمة العلوية بعد التحقق.

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

OpenID Connect

OpenID Connect هو طريقة مصادقة وتفويض تعتمد على بروتوكول OAuth2.0، توفر حل تطبيق كامل نسبيًا. ستسمح سياسة OpenID Connect في بوابة API للخدمة العلوية بالحصول على معلومات المستخدم من مزود الهوية (IdP)، وبالتالي حماية أمان API. من مزودي الهوية الشائعين Keycloak، Ory Hydra، Okta، Auth0، إلخ. على سبيل المثال، Apache APISIX، تدفق عمل سياسة OpenID Connect في البوابة هو كما يلي:

1. يرسل العميل طلبًا إلى البوابة
2. بعد استلام الطلب، ترسل البوابة طلب مصادقة إلى IdP
3. سيتم توجيه المستخدم إلى الصفحة المقدمة من IdP لإكمال تسجيل الدخول والمصادقة
4. يعيد IdP التوجيه إلى البوابة مع رمز المصادقة
5. تطلب البوابة رمز وصول من IdP من خلال الرمز للحصول على معلومات المستخدم
6. يمكن للبوابة حمل معلومات المستخدم عند إعادة توجيه الطلب إلى الأعلى

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

لمزيد من طرق المصادقة والتفويض في APISIX، يرجى الرجوع إلى مصادقة بوابة API.

سياسة الأمان

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

فيما يلي عدة سياسات أمان مهمة لبوابة API:

قيود الوصول إلى IP

تقييد سياسة IP وصول عملاء معينين إلى API عن طريق تعيين عناوين IP معينة أو CIDR في قائمة السماح أو الحظر لمنع الوصول غير المصرح به إلى البيانات الحساسة. التكوين الصحيح لهذه السياسة سيحسن بشكل كبير أمان API ويمكن من تحقيق حوكمة أمان أعلى لـ API.

حظر URI

تقوم سياسة حظر URI بقطع الطلبات الخطيرة المحتملة لـ API عن طريق تعيين بعض قواعد URI. على سبيل المثال، بعض الهجمات الأمنية تكتشف الثغرات المحتملة عن طريق استنشاق مسار URI ثم الهجوم. يوفر Apache APISIX مكون uri-blocker لحظر الطلبات الخطيرة لـ API. يمكن أيضًا تعيين التعبيرات العادية من خلال مكون uri-blocker. ستقوم بوابة API بحظر الطلب إذا تطابق الطلب مع القاعدة. على سبيل المثال، إذا قمنا بتكوين root.exe، admin، يمكن لهذا المكون حظر طلبات */root.exe و */admin لحماية أمان API بشكل أكبر.

CORS

CORS (مشاركة الموارد عبر المصادر) هي سياسة أمان المتصفح لطلبات عبر النطاقات. بشكل عام، قبل إرسال طلب xhr في المتصفح، سيتحقق المتصفح مما إذا كان عنوان الطلب والعنوان الحالي في نفس المصدر. سيتم إرسال الطلبات داخل نفس المصدر مباشرة. وإلا، سيرسل المتصفح أولاً طلبًا مسبقًا من نوع OPTION عبر النطاقات. ستكون هناك إعدادات CORS في رأس الاستجابة، مثل الطرق التي يُسمح بحملها في الطلبات عبر النطاقات. سيقرر المتصفح ما إذا كان سيتم إرسال طلب رسمي بناءً على هذه المعلومات. لمزيد من التفاصيل، يرجى الرجوع إلى CORS.

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

CSRF

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

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

سياسة معالجة حركة المرور

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

تحديد المعدل

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

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

يمكن تعيين المتغير لحساب الطلبات في الطلب أو كرأس طلب معين، على سبيل المثال، لتعيين سياسة تحديد السرعة المقابلة وفقًا لعناوين IP مختلفة لتحقيق مرونة أفضل.

كسر الدائرة

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

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

تقسيم حركة المرور

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

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

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

يدعم APISIX كلا النشرين من خلال مكون traffic-split، مما يجعل نشر الأعمال أكثر ملاءمة وموثوقية.

إعادة كتابة الاستجابة

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

يوفر APISIX مكون إعادة كتابة الاستجابة لتعديل معلومات Body أو Header التي يتم إرجاعها من الخدمات العلوية ويدعم إضافة أو حذف رؤوس الاستجابة، تعيين قواعد لتعديل جسم الاستجابة، إلخ. هذا مفيد في سيناريوهات مثل تعيين رؤوس استجابة CORS لطلبات عبر النطاقات أو تعيين موقع لإعادة التوجيه.

من ناحية أخرى، يوفر APISIX proxy-rewrite لإعادة كتابة الطلب. يمكن للمكون أيضًا التعامل مع المحتوى المطلوب الذي يتم تمريره إلى الخدمة العلوية. يمكنك إعادة كتابة URI الطلب، الطريقة، رأس الطلب، إلخ، مما يوفر راحة لمعالجة الأعمال في العديد من السيناريوهات.

حقن الأخطاء

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

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

تحويل البروتوكولات

يمكن لسياسة تحويل البروتوكولات التحويل بين بعض البروتوكولات القياسية، مثل طلبات HTTP الشائعة وgRPC. يوفر Apache APISIX مكون grpc-transcode الذي يمكنه تحويل وإعادة توجيه طلب HTTP إلى خدمات من نوع gRPC. يتم إرجاع الاستجابة إلى العميل بتنسيق HTTP. بهذه الطريقة، يمكن للعميل التركيز فقط على HTTP دون الاهتمام بنوع gRPC العلوي.

سياسة المراقبة

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

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

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

تنقسم سياسات المراقبة بشكل عام إلى ثلاث فئات وفقًا لنوع بيانات الإخراج: التتبع، المقاييس، والتسجيل.

التتبع

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

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

المقاييس

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

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

التسجيل

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

يمكن لسياسة التسجيل تخزين السجلات في بوابة API في قرص الخادم أو دفعها إلى بعض خوادم السجلات الأخرى، مثل خادم سجل HTTP، خادم سجل TCP، خادم سجل UDP، إلخ، أو أنظمة سجلات أخرى مثل Kafka، RocketMQ، Clickhouse.

الخلاصة

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

لمزيد من المعلومات المتعلقة ببوابات API، يرجى زيارة المدونات وAPI7.ai للحصول على المزيد من الدعم التجاري.