إدارة واجهات API · Kong Gateway
بوابة API للمؤسسات في المملكة: ما الذي تفعله، وأين تعمل، وكيف تختارونها
بوابة API هي نقطة الدخول الموحدة أمام واجهات API لديكم. توجّه كل طلب إلى الخدمة الصحيحة، وتطبّق القواعد نفسها على كل استدعاء: التحقق من الهوية، وحدود الاستخدام، وفحص الطلبات، والتسجيل. فلا تضطر كل خدمة إلى تطبيقها بمفردها. وفي الجهات السعودية يكون سؤال التصميم الأول عادةً عن مكان تشغيل البوابة، لأن المكوّن الذي يفحص محتوى الطلبات يعمل حيثما تمر الحركة. وتتولى إنتركي من الرياض تصميم بوابات API وتطبيقها وتشغيلها على Kong Gateway للجهات في المملكة.
نُشر في 5 دقائق قراءة
الخلاصة
- ما الذي تفعله: التوجيه، والتحقق من الهوية، وحدود الاستخدام، والتحقق من صحة الطلبات، والتسجيل والمقاييس، في طبقة واحدة لكل واجهات API.
- أين تعمل: بقاعدة بيانات، أو دونها مع إعدادات من ملف، أو مقسّمة إلى مستوى تحكم ومستويات بيانات. ويمكن على Kubernetes أن تعمل أيضًا كمدخل للعنقود (Ingress).
- ما الذي يحدد التصميم: هل يُسمح بخروج محتوى الطلبات من المملكة، ومن يشغّل المنصة، وكم فريقًا ينشر واجهات API.
- ما الذي لا تفعله: لا تجعل الخدمة غير الآمنة آمنة، فالخدمات خلفها تحتاج إلى مراجعة أمنية خاصة بها.
- ما الذي تطبّقه إنتركي: Kong Gateway، وهو منتج لشركة Kong Inc.، إحدى الشركات الشريكة لإنتركي في التقنية.
ما الذي تفعله بوابة API
| الوظيفة | ما الذي تفعله | أمثلة من Kong Gateway (حسب Kong Plugin Hub في 2 نوفمبر 2026) |
|---|---|---|
| التوجيه | ترسل كل طلب إلى الخدمة والإصدار الصحيحين | المسارات (Routes) والخدمات (Services) المعرّفة في الإعدادات |
| التحقق من الهوية | تتحقق من هوية الجهة المستدعية قبل وصول الطلب إلى الخدمة | Key Auth وJWT وBasic Auth وOAuth 2.0، وOpenID Connect وMutual TLS في إصدار Enterprise |
| التحكم في الوصول | تحدد المستهلكين والشبكات المسموح لها باستدعاء كل واجهة | ACL وIP Restriction |
| حدود الاستخدام | تحمي الخدمات من الضغط الزائد وتطبّق الاستخدام العادل لكل مستهلك | Rate Limiting وRequest Size Limiting، وRate Limiting Advanced في إصدار Enterprise |
| التحقق من صحة الطلبات | ترفض الطلبات غير السليمة أو غير المتوقعة قبل وصولها إلى الخدمة | Request Validator وOAS Validation في إصدار Enterprise |
| الوصول من المتصفح | تحدد مصادر الويب المسموح لها باستدعاء الواجهة | CORS |
| قابلية المراقبة | تسجّل كل استدعاء، فيمكن ربط أي فشل بالجهة المستدعية | سجلات ومقاييس تُرسل إلى منصة المراقبة لديكم |
وتتغير الميزات التي تتطلب إصدار Enterprise من وقت لآخر، لذا راجعوا Kong Plugin Hub الحالي عند التخطيط.
الفرق بين بوابة API وإدارة واجهات API ووحدة التحكم في الدخول
- بوابة API: طبقة التشغيل التي يمر عبرها كل استدعاء، وهي موضوع هذه الصفحة.
- إدارة واجهات API: الممارسة الأوسع المحيطة بها: حصر كل الواجهات، وسياسة مكتوبة، وإجراءات ضم المستهلكين، وإدارة الإصدارات وإيقافها، والتشغيل. والبوابة هي التي تطبّق السياسة. تعرّفوا على خدمات إنتركي لإدارة واجهات API.
- وحدة التحكم في الدخول (Ingress Controller): المكوّن الذي يُدخل الحركة الخارجية إلى عنقود Kubernetes. ويشغّل Kong Ingress Controller بوابة Kong Gateway في هذا الدور، ويدعم موارد Ingress في Kubernetes وواجهة Gateway API (HTTPRoute وTCPRoute وUDPRoute)، ويضبط Kong عبر موارد Kubernetes المخصصة.
- بوابة الخدمات المصغّرة: بوابة API نفسها حين توضع أمام خدمات صغيرة كثيرة، فلا تحمل كل خدمة آلية التحقق من الهوية وحدود الاستخدام الخاصة بها.
روابط ذات صلةتعرّفوا على خدمات إنتركي لإدارة واجهات API
أين تعمل البوابة: ثلاثة أشكال للنشر
توثّق Kong ثلاث طرق لتشغيل Kong Gateway:
| الشكل | كيف يعمل | يناسب | المقابل |
|---|---|---|---|
| التقليدي (بقاعدة بيانات) | تتصل كل عقدة بقاعدة بيانات، وتعمل مستوى تحكم ومستوى بيانات في آن واحد | الفرق التي تحتاج إلى إضافات تعتمد على قاعدة البيانات، مثل تحديد الاستخدام بنمط cluster أو OAuth 2.0 | تحمل كل عقدة الإعدادات كاملة، فاختراق عقدة واحدة يكشفها كلها |
| دون قاعدة بيانات (DB-less) | تُحمَّل الإعدادات من ملف YAML أو JSON تصريحي وتُحفظ في الذاكرة، دون قاعدة بيانات | البيئات الصغيرة أو الثابتة التي تُدار بالكامل ككود | لا تُعدَّل الإعدادات عبر واجهة Admin API، وبعض الإضافات التي تحتاج إلى قاعدة بيانات غير متوافقة |
| الهجين | يحمل مستوى التحكم الإعدادات، وتنقل مستويات البيانات الحركة دون قاعدة بيانات خاصة بها | تعدد البيئات أو المواقع، مع مكان واحد لإدارة السياسات | مستويان يحتاجان إلى تشغيل. وإذا توقف مستوى التحكم تواصل مستويات البيانات العمل بآخر إعدادات معروفة لديها |
السؤال في المملكة هو أين يعمل كل مستوى. فإذا كان محتوى الطلبات لا يجوز أن يغادر المملكة، فيجب أن يعمل داخلها أيضًا مستوى البيانات الذي يفحصه. ويمكن تشغيل Kong بإدارة ذاتية، بحيث يعمل المستويان كلاهما على بنية تحتية تشغّلونها في المملكة. وتقارن صفحة تطبيق Kong في موقع إنتركي بين خيارات الإدارة الذاتية والهجين وKubernetes، ومتى يناسب كل منها.
ما الذي تطلبونه من بوابة API
استخدموا هذه القائمة لتقييم أي بوابة، بما في ذلك العرض المقدم من إنتركي:
- الإعدادات ككود. يُعرَّف كل مسار وإضافة ومستهلك في إعدادات تخضع لإدارة الإصدارات، وتديرها أداة decK من Kong بأسلوب تصريحي.
- مصدر واحد للهوية. يُسند التحقق من الهوية إلى منصة الهوية التي تشغّلونها الآن، دون مخزن ثانٍ لبيانات الدخول داخل البوابة.
- حدود لكل مستهلك، تُحدَّد من قائمة الواجهات لا من القيم الافتراضية، مع تنبيه عند بلوغ أي مستهلك حده.
- قياس افتراضي لكل استدعاء. يُسجَّل كل استدعاء ويُقاس في منصة المراقبة لديكم.
- ترقيات تُجرَّب مسبقًا، مع خطة للتراجع قبل كل تغيير في الإصدار.
- تجديد دوري للأسرار، للشهادات والمفاتيح وفق جدول.
- قواعد للإصدارات وإيقافها، كي لا يعطّل تغيير واحد ثلاثة مستهلكين في الوقت نفسه.
- اختبار المحتوى العربي. تمر البيانات المكتوبة من اليمين إلى اليسار والبيانات المختلطة اللغة دون تغيير.
ما الذي لا تعالجه البوابة
تطبّق البوابة القواعد نفسها على كل استدعاء، لكنها لا تجعل الخدمة غير الآمنة آمنة. فضعف التحقق من الصلاحيات داخل الخدمة، والبيانات الزائدة في الاستجابات، والمكتبات غير المحدّثة، كلها تحتاج إلى معالجة في الخدمة نفسها. وتحتاج الواجهات المتاحة للعموم إلى سياسات أشد، وإلى مراجعة لإعدادات البوابة.
كيف تنفّذ إنتركي بوابة API
-
الحصر والسياسة.
نحصر الواجهات التي تتيحونها والجهات التي تستدعيها، ثم نكتب السياسة التي ستطبّقها البوابة.
-
النشر بالشكل المناسب.
نختار بين التقليدي ودون قاعدة بيانات والهجين، ونحدد مكان تشغيل كل مستوى، ونقرر هل يدخل Kubernetes Ingress في التصميم.
-
السياسة كإعدادات.
نصوغ التحقق من الهوية والحدود وفحص الطلبات في إعدادات تخضع لإدارة الإصدارات.
-
نقل المستهلكين.
ننقل كل مستهلك إلى البوابة، ثم نغلق المسارات المباشرة القديمة.
-
التشغيل.
تشغّل إنتركي البوابة كخدمة مُدارة، أو تسلّم مستودعات الإعدادات وأدلة التشغيل لفريقكم.
وتُسعَّر تراخيص Kong، حين يلزم إصدار Enterprise، وفق شروط Kong إلى جانب خدمات إنتركي. ويمكن للجهات التي اختارت منتج بوابة آخر أن تستفيد من ممارسة إنتركي في إدارة واجهات API. وإذا كنتم توجّهون حركة إلى النماذج اللغوية الكبيرة أيضًا، فاطّلعوا على Kong AI Gateway.
أسئلة شائعة
كيف نختار بوابة API؟
لا توجد بوابة تناسب كل الجهات. قيّموا كل خيار وفق المتطلبات أعلاه، ومكان بقاء البيانات، ومن سيتولى التشغيل. وتطبّق إنتركي Kong Gateway.
هل بوابة API هي نفسها إدارة واجهات API؟
لا. البوابة طبقة التشغيل التي تطبّق السياسة، أما إدارة واجهات API فتشمل أيضًا الحصر والسياسة وضم المستهلكين وإدارة الإصدارات والتشغيل.
هل يمكن تشغيل البوابة كاملةً داخل المملكة؟
نعم. في النشر بإدارة ذاتية يعمل مستوى الحركة ومستوى الإعدادات كلاهما على بنية تحتية تشغّلونها في المملكة.
نشغّل Kubernetes الآن، فهل ما زلنا نحتاج إلى بوابة؟
يشغّل Kong Ingress Controller بوابة Kong Gateway كمدخل للعنقود، فيتولى مكوّن واحد إدخال الحركة إلى العنقود وتطبيق سياسات البوابة. ويتوقف كفاية ذلك على عدد الواجهات الموجودة خارج العنقود.
هل نحتاج إلى إصدار Enterprise؟
يتوقف ذلك على الميزات التي تحتاجونها. فبعض الإضافات، ومنها OpenID Connect وRate Limiting Advanced، مدرجة على أنها خاصة بإصدار Enterprise. ونؤكد الإصدار المناسب لمتطلباتكم قبل تقديم عرض السعر.
التالي
صفحات ذات صلة
الخطوة التالية
ناقشوا بوابة API لديكم
أخبرونا بعدد الواجهات التي تتيحونها تقريبًا، ومن يستدعيها، وأين يجب أن تبقى البيانات، وهل تشغّلون Kubernetes. وسنقترح شكل النشر المناسب والخطوات الأولى لحصر الواجهات.
أو مباشرةً
+966-11-2180999 [email protected]أبراج التعاونية، البرج الشمالي، الطابق السابع، طريق الملك فهد، العليا، ص.ب. ٥٦٨٣٥، الرياض ١١٥٦٤، المملكة العربية السعودية