لماذا اختارت Jiakaobaodian APISIX Ingress Controller

مع انتشار Kubernetes (المعروف اختصارًا بـ K8s)، أصبح لدينا خيارات أكثر من وحدة تحكم NGINX Ingress الافتراضية الرسمية للاختيار من بينها، وأصبح Apache APISIX Ingress Controller أيضًا خيارًا شائعًا للعديد من الشركات. المزيد والمزيد من الشركات تقوم تدريجيًا باستبدال وحدة تحكم Ingress الخاصة بها بوحدة تحكم APISIX Ingress.

الخلفية

تأسست شركة Wuhan Mucang Technology Co., Ltd في عام 2011، ومنتجاتها الرئيسية هي عشرات التطبيقات المتعلقة بالسيارات مثل Jiakaobaodian. منذ تأسيسها قبل أكثر من 10 سنوات، تابعت الشركة تطور التكنولوجيا وبدأت في تبني الحوسبة السحابية الأصلية في عام 2019، وبدأت مختلف المشاريع في الشركة في استخدام Kubernetes.

ولكن في ذلك الوقت، وبما أن K8s كانت قد ظهرت للتو، كانت هناك خيارات قليلة لبوابات دخول الحركة. لذلك، استخدمنا وحدة تحكم Ingress الافتراضية – NGINX Ingress Controller – لمدة تقارب 4 سنوات. ومع ذلك، خلال تلك الفترة، أصبح من الواضح بشكل متزايد أن NGINX Ingress Controller لم يعد قادرًا على تلبية احتياجاتنا، مما أجبرنا على إجراء اختيار جديد. بعد مقارنة وحدات تحكم Ingress الرئيسية، قررنا استخدام Apache APISIX كبوابة دخول الشركة.

مشكلة NGINX Ingress Controller

الخدمات في الشركة تستخدم بروتوكول HTTP وبروتوكول TCP، وفقط مهندسو التشغيل والصيانة يعرفون بالضبط كيفية تكوين الوكيل TCP من خلال NGINX Ingress Controller. ومع ذلك، فإن القوى العاملة في التشغيل والصيانة محدودة. سيكون من الأفضل إذا قمنا بتسليم بعض العمليات والتكوينات الأساسية لـ NGINX إلى فريق التطوير، وذلك لتوفير تكاليف التشغيل والصيانة.

بالإضافة إلى كل ذلك، واجهنا أيضًا المشكلات التالية:

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

لهذه الأسباب، قررنا استبدال وحدة تحكم Ingress السابقة بوحدة تحكم جديدة.

لماذا APISIX Ingress Controller

قمنا بالتحقيق في Apache APISIX ووحدات تحكم Ingress الأخرى، وقارناها من حيث الأداء، وسهولة الاستخدام، وقابلية التوسع، والتكامل مع المنصة، واخترنا في النهاية APISIX Ingress Controller كبوابة دخول الحركة لـ K8s للأسباب التالية.

قابلية توسع جيدة؛
دعم التحميل الساخن للتكوين؛
أداء عالي؛
الكثير من الإضافات؛
دعم CRD للتكامل مع منصة الحاويات المطورة ذاتيًا.

الهيكل العام

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

رسم تخطيطي للهيكل

طريقة النشر

يتم نشر أعمالنا على منصات سحابية مختلفة (Huawei Cloud، Tencent Cloud، Alibaba Cloud)، ويمكننا نشر أعمالنا بسرعة من خلال Helm Chart، والذي يدعمه APISIX Ingress Controller. عند استخدام APISIX Ingress Controller، إذا وجدنا ميزات يمكن تحسينها، فإننا نقوم أيضًا بتقديم PRs لمساعدة المجتمع على تحديث وتطوير الميزات. في عملية النشر الفعلية، قمنا بتخصيص بعض التكوينات وفقًا لخصائص أعمالنا، مثل:

إنشاء NameSpace من خلال K8s، ونشر APISIX و APISIX Ingress Controller في NameSpace مختلفة، وفصل الحركة وفقًا لخطوط المنتجات وأهمية الخدمة؛
تحسين معلمات نواة Linux TCP في initContainer لـ APISIX؛
نظرًا لأننا بحاجة إلى فصل الحركة من حيث خطوط المنتجات وأهمية الخدمة، يجب تكوين معلومات ClassName لـ K8s.

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

التكامل مع منصات الحاويات المطورة ذاتيًا باستخدام CRD

يدعم APISIX Ingress Controller حاليًا العديد من موارد CRD، لذلك يمكننا استخدام موارد CRD لدمج APISIX Ingress Controller مع منصة الحاويات الخاصة بنا. ومع ذلك، نظرًا لأن APISIX لا يوفر Java Client، نحتاج إلى استخدام أداة توليد التعليمات البرمجية التي توفرها K8s لإنشاء النموذج واستخدام CustomObjectApi لإدارة CRD. يتم ربط كائنات ApisixRoute بتطبيقات منصة الحاويات وهيكلتها مع الكائنات الأساسية، مما يسمح لكل من موظفي العمليات ومديري المشاريع بالعمل في منصة الحاويات.

سيناريوهات التطبيق

المصادقة

قبل استخدام Apache APISIX، قمنا بتنفيذ المصادقة بناءً على بوابة Istio، وبعد الانتقال إلى Apache APISIX، اخترنا استخدام مكون forward-auth، والذي ينقل بذكاء منطق المصادقة والتفويض إلى خدمة مصادقة خارجية. يتم توجيه طلب المستخدم إلى خدمة المصادقة من خلال البوابة، وعندما تستجيب خدمة المصادقة بحالة غير 20x، يتم حظر الطلب الأصلي واستبدال النتيجة. بهذه الطريقة، يمكن إرجاع تقرير خطأ مخصص أو إعادة توجيه المستخدم إلى صفحة المصادقة في حالة فشل المصادقة.

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

التحكم في التدفق

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

لذلك، نستخدم مكونات limit-conn، limit-req، و limit-count في APISIX لتحديد الطلبات ومنع الانهيار الكامل. من الأسهل تحديد التدفق والسرعة عن طريق تعديل المكونات، وبفضل آلية التحميل الساخن في APISIX، لا حاجة لإعادة تشغيل المكونات عند تكوينها، لذلك يمكن أن تصبح فعالة على الفور. من خلال التحكم في الحركة، يمكن أيضًا إيقاف بعض الهجمات الخبيثة وحماية أمان النظام. قمنا أيضًا بتنفيذ HPA (Horizontal Pod Autoscaler) في منصة K8s، والتي تقوم بالتوسع التلقائي صعودًا وهبوطًا بمجرد أن تكون كمية الحركة كبيرة جدًا أو صغيرة جدًا، مع مكونات تحديد التدفق والسرعة في APISIX لمنع الانهيارات الضخمة.

المراقبة

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

مع مكون kafka-logger، يمكن كتابة سجلات الوصول والأخطاء التي يتم إنشاؤها بواسطة APISIX مباشرة إلى مجموعة Apache Kafka. مع هذه الميزة، يمكن لمجموعة APISIX التوسع بشكل أفقي بدون حالة دون الحاجة إلى تهيئة الأقراص، أو تدوير السجلات، أو تنفيذ عمليات أخرى. إذا تم تخزين السجلات محليًا، نحتاج إلى القيام ببعض العمليات الإضافية ولا يمكن تحقيق التوسع السريع. من خلال إرسال السجلات إلى مجموعة Apache Kafka، يمكننا أيضًا تحليل السجلات في الوقت الفعلي، وتحسين النظام وتحسينه بناءً على نتائج التحليل.

الخلاصة

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

المزيد والمزيد من الفرق تستخدم Apache APISIX Ingress Controller في بيئة الإنتاج. إذا كنت تستخدم أيضًا APISIX Ingress Controller، نشجعك على مشاركة حالات الاستخدام الخاصة بك في المجتمع.