APISIX يدفع إلى ترقية بوابة API في Tencent BlueKing

هذه الدراسة الحالة تمت مشاركتها بواسطة لي تشو، المدير الفني لمنصة BlueKing PaaS، مجموعة IEG (مجموعة الترفيه التفاعلي)، Tencent

حول BlueKing

BlueKing هي مجموعة داخلية من منصة PaaS متكاملة للبحث والتشغيل تم تطويرها داخل Tencent IEG (مجموعة الترفيه التفاعلي)، وتخدم وحدات أعمال متعددة ومنصات داخلية. دورها هو تقديم خدمات دورة الحياة الكاملة لمشاريع الشركة في مراحل CI (التكامل المستمر)، CD (التسليم المستمر)، و CO (التشغيل المستمر).

نظرة عامة

التحديات

• أداء منخفض: أداء منخفض في ظروف التزامن العالي وخوارزمية التوجيه، مما يؤدي إلى بطء في مطابقة التوجيه وإعادة التوجيه
• ضغط هائل على قاعدة البيانات: يتم تخزين سياسات التوجيه في MySQL. وبالتالي، تتعرض قاعدة البيانات لضغط كبير مع العديد من طلبات الاسترجاع
• تكاليف عالية: يتم استخدام Redis على نطاق واسع في العديد من السيناريوهات، مما يتسبب في تكاليف إضافية عالية
• عزل غير كافٍ: لا يمكن تحقيق العزل الفعلي؛ اتصالات طويلة الأجل غير مستقرة
• دعم بروتوكول واحد فقط: يدعم فقط بروتوكول HTTP
• لا يدعم التوجيه الديناميكي: غير ودود لإصدار Canary وغير قادر على تغليف السيناريوهات
• نقص في اكتشاف الخدمة: غير ودود لهندسة الخدمات الصغيرة

الأهداف

• تحويل قدرات المنصة إلى خدمات صغيرة مستقلة، وإجراء تحويل إلى خدمات صغيرة لتشكيل بنية PaaS
• استخدام تقنية low-code لتطوير SaaS بكفاءة لاستخدام قدرات الخدمات الصغيرة لمنصة PaaS
• الاستجابة بمرونة لسيناريوهات الخدمات المختلفة من خلال SaaS متنوعة

النتائج

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

تنوع وتعقيد الألعاب يتطلب بوابة API لـ BlueKing

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

في مواجهة سيناريو أعمال معقد يتضمن عددًا كبيرًا من البنى غير المتجانسة، تحتاج BlueKing، كمنصة داخلية، إلى تحويل بوابة API الخاصة بها لتطوير بنية PaaS، ثم استخدام تقنية low-code لتطوير SaaS بكفاءة واستخدام قدرات الخدمات الصغيرة لـ PaaS، واستخدام SaaS متنوعة للتعامل مع سيناريوهات الخدمات.

لتصوير بنية BlueKing بشكل مجرد، يمكننا الحصول على مخطط API.

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

• من ناحية أخرى، مع تطور تقنية cloud-native، تم نشر العديد من SaaS والمنصات الداخلية الآن في مجموعات K8s. يضع هذا السيناريو متطلبات جديدة للبوابة، مثل التحكم الموحد في حركة المرور لطلبات الاستدعاء الخارجية من خلال بوابة حركة مرور موحدة أو بوابة API.

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

مع تطور متطلبات الأعمال الداخلية، تحتاج بوابة API لـ BlueKing إلى دعم سيناريوهات متزايدة التنوع.

بوابة API لـ BlueKing 1.0

كانت بوابة API لـ BlueKing 1.0 تهدف إلى السماح للمستدعي للمنصات (بما في ذلك SaaS المختلفة ومحركات العمليات) باستدعاء بوابة API مباشرة لإكمال تحويل البروتوكول والتحقق من الصلاحيات من خلال البوابة.

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

بعد عدة سنوات، مع زيادة الطلبات والسيناريوهات المعقدة، بدأت عيوب بوابة API لـ BlueKing 1.0 تظهر تدريجيًا. على سبيل المثال:

• أداء إطار العمل ضعيف: تم اختيار إطار عمل Django للتنفيذ. أداؤه متوسط في سيناريوهات التزامن العالي ويصبح مرهقًا عند معالجة الطلبات الضخمة.

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

• قواعد البيانات تحت ضغط: يتم تخزين جميع سياسات التوجيه في MySQL. عندما تكون هناك العديد من القواعد، يتم تنفيذ العديد من طلبات الاسترجاع مع ضغط استعلام كبير.

• تكاليف شبكة عالية: يتم استخدام Redis بشكل كبير في سيناريوهات مختلفة، مما يؤدي إلى تكاليف شبكة إضافية عالية.

بوابة API لـ BlueKing 2.0

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

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

بشكل عام، تعالج بوابة API لـ BlueKing 2.0 مشكلات الأداء ومعظم النقاط المؤلمة التي واجهتها في الإصدار 1.0. ولكن مع مرور الوقت، بدأت مشكلات جديدة تظهر ببطء.

• عزل غير كافٍ: لا يمكن تحقيق العزل الفعلي الحقيقي؛ عملية الإصدار ستؤدي إلى قطع الاتصالات طويلة الأجل

• دعم بروتوكول واحد فقط: يدعم فقط HTTP، والطلب على البروتوكولات غير HTTP يتزايد في السيناريوهات الفعلية

• لا يدعم قواعد التوجيه الديناميكية: لا يدعم قواعد التوجيه الديناميكية المطابقة بالشروط؛ غير ودود بما يكفي لسيناريوهات إصدار Canary؛ غير قادر على التجميع والتغليف القائم على السيناريو

• نقص في قدرة اكتشاف الخدمة: نقص في قدرة اكتشاف الخدمة التلقائية، غير ودود لهندسة الخدمات الصغيرة

APISIX تبرز في اختيار التكنولوجيا لبوابة API لـ BlueKing

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

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

تتكون مكونات بنية البوابة الموزعة بشكل رئيسي من فئتين: جانب الإدارة ونسخة البوابة الصغيرة.

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

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

قال تشو إن BlueKing اختارت APISIX لأنها تم تنفيذها بناءً على NGINX + Lua، لذا فإن أدائها العام لديه مزايا مقارنة بتلك المبنية على Golang. علاوة على ذلك، APISIX مميزة في قابلية التوسع، كما تدعم توسيع القدرات من خلال ملحقات متعددة اللغات. تمت مشاهدة العديد من حالات الاستخدام النموذجية.

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

بوابة API لـ BlueKing 3.0 بناءً على APISIX

في بيئة cloud-native، يعتبر K8s المكون الأساسي الأكثر أهمية الذي يحتاج إلى الاهتمام. لأن البوابة الصغيرة بأكملها مصممة لبيئة cloud-native، فإن الإصدار 3.0 لديه تصميم بنية جديد يعتمد على K8s.

الجزء الأساسي هو استخدام الموارد المخصصة CRD التي يوفرها K8s لتحقيق مجموعة العمليات والتوسع لبوابة API.

كما هو موضح في الشكل أعلاه، تقدم البوابة مجموعة من موارد K8s CRD، بما في ذلك BkGatewayStage (بيئة البوابة)، BkGatewayService (خدمة الخلفية)، إلخ. من خلال هذه CRDs، يمكن لـ BlueKing التحكم في السلوك المحدد لكل نسخة بوابة صغيرة.

العديد من "المشغلين" في الشكل هم الجزء الأساسي من هذه البنية. في الأعلى يوجد خدمة Plugin Operators، والتي تحتوي على سلسلة من مشغلي الملحقات. على سبيل المثال، المشغل المسؤول عن اكتشاف الخدمة سيكتب عنوان خدمة الخلفية المسجلة في مركز اكتشاف الخدمة في مجموعة K8s.

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

تنقسم هذه المجموعة من البوابة الصغيرة إلى نوعين من النشر:

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

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

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

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

بناءً على البنية والأنماط المذكورة أعلاه، توفر بوابة API لـ BlueKing 3.0 وظائف أكثر ثراءً بدعم من APISIX. على سبيل المثال، إدارة الموارد، إصدار الإصدارات، المستندات التلقائية، SDK، إدارة الأذونات، القدرة على المراقبة، المراقبة والتنبيه، وحماية الأمان.

سيناريوهات عملية لبوابة BlueKing 3.0 باستخدام APISIX

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

اكتشاف الخدمة

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

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

ثم يقرأ المسؤول معلومات العنوان ذات الصلة لمركز اكتشاف الخدمة من خلال واجهة اكتشاف الخدمة المدمجة مثل Watcher و Lister ويعيد كتابة العنوان الذي تم الحصول عليه مرة أخرى في مجموعة K8s من خلال مورد CRD BkGatewayEndpoints.

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

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

المصادقة الموحدة

جزء المصادقة الموحدة بسيط نسبيًا. في الممارسة اليومية، هناك طلبات من ثلاثة مصادر: المتصفحات، المنصات، والمستخدمين الفرديين. بناءً على APISIX، قامت BlueKing بتخصيص ملحق مصادقة، BK-Auth، لتحقيق المصادقة الموحدة.

تتم عملية التنفيذ المحددة كما هو موضح في الشكل أعلاه. بعد الطلب، سيقرأ الملحق معلومات الاعتماد ذات الصلة من الرأس ثم يستدعي خدمة المصادقة BK-Auth بشكل موحد للتحقق من الاعتماد وقراءة معلومات SaaS المقابلة. ثم يستخدم الملحق المفتاح الخاص المتفق عليه مع الخلفية لإصدار رمز JWT وكتابته في رأس الطلب، وأخيرًا، كتابته في متغير APISIX.

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

يمكن للطلبات من العميل أولاً جلب معلومات تطبيق SaaS من خلال رابط المصادقة، ثم التفاعل مع ملحق المصادقة بناءً على RPC عند تمرير ext-plugin. في هذا الوقت، سيستفسر ملحق المصادقة مباشرة عن البيانات المتعلقة بالمصادقة في الذاكرة المؤقتة، والتي تتم مزامنتها من جانب الإدارة من خلال آلية كاملة وتزايدية، ثم يكمل المصادقة.

التوجيه الديناميكي

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

كمستخدم، غالبًا ما تحتاج إلى طلب APIServers لهذه المجموعات. عندما يدخل طلب المستخدم إلى البوابة الصغيرة، تحدد البوابة أي مجموعة APIServer لإعادة توجيه الطلب إليها بناءً على مسار الطلب.

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

بالنسبة للمجموعات غير المتصلة مباشرة، يتم أولاً إنشاء مدير مجموعة BCS upstream ثم التفاعل مع وكيل BCS من خلاله، وأخيرًا تمرير الطلب إلى APIServer للمجموعة.

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

إدارة شهادات العميل

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

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

تستخدم هذه العملية بعض موارد CRD وموارد Secret الرسمية لـ K8s وسيتم التوفيق بشكل مستمر من قبل خدمة المشغل الأساسي، مثل العثور على الشهادة المقابلة وفقًا لاسم النطاق. سيتم في النهاية عكس تكوين شهادة العميل الفعال في التكوين ذي الصلة لـ APISIX Service. (كما هو موضح في المربع الأحمر في الجزء العلوي الأيمن من الشكل أعلاه)

ملخص

Apache APISIX هي بوابة API مفتوحة المصدر، ديناميكية، قابلة للتوسع، وعالية الأداء لجميع واجهات برمجة التطبيقات والخدمات الصغيرة الخاصة بك. بعد التبرع بها إلى مؤسسة Apache Software Foundation بواسطة API7.ai، نمت APISIX لتصبح مشروع Apache مفتوح المصدر من المستوى الأعلى.

مع تطور هندسة الخدمات الصغيرة ومشاريع الأعمال الداخلية، لم تعد بوابة API السابقة تلبي الاحتياجات. لم تقم Tencent BlueKing بحل المشكلة فحسب، بل وفرت أيضًا ميزات أكثر ثراءً باستخدام APISIX.