من NGINX إلى APISIX – إعادة تعريف ديناميكيات بوابات شركات الطيران

نظرة عامة

حول

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

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

التحديات

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

النتائج

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

الخلفية

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

1. حالات NGINX المتعددة والنطاقات

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

2. إصدارات NGINX المختلفة وصعوبة ترقية الإضافات

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

3. عدم وجود معايير لتكوينات NGINX

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

4. نقص الميزات الحديثة للبوابة

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

اختيار البوابة لتلبية الاحتياجات التجارية الدقيقة

لحل التحديات التي واجهتها مع NGINX، حددت هذه الشركة الرائدة ثلاث متطلبات أساسية رئيسية لحل بوابة جديد:

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

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

لماذا لم يتم اختيار OpenResty

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

ومع ذلك، مقارنة بـ Kong و APISIX، كانت النسخة المفتوحة المصدر من OpenResty تفتقر إلى إضافات شاملة ولوحة تحكم للتكوين المرئي. كان على المستخدمين الانخراط في الترميز لتلبية بعض الوظائف الأساسية.

لماذا لم يتم اختيار Kong

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

في اختبارات الضغط، تفوقت APISIX على Kong، حيث أظهرت أداءً مثيرًا للإعجاب — ضعف أداء Kong بدون إضافات وحتى عشر مرات أفضل مع تمكين إضافات الحد من المعدل و Prometheus. بالإضافة إلى ذلك، أظهرت APISIX، المبنية على OpenResty، قدرات توجيه ممتازة، مما عزز ثقة الفريق.

لماذا لم يتم اختيار Envoy

على الرغم من الميزات الرائعة لـ Envoy، إلا أن لغة C++ ومنحنى التعلم الأكثر انحدارًا، خاصة بالنسبة لقدرات الفريق التقنية، أدت إلى قرار بعدم اختيار Envoy كحل بوابة مفضل.

في النهاية، اختار الفريق التقني APISIX كبوابة جديدة بسبب وظائفه وأدائه المعترف بهما.

لماذا تبرز APISIX؟

برزت APISIX مقارنة بـ Kong لسببين رئيسيين.

• لوحة تحكم APISIX

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

• مشروع Apache مفتوح المصدر

  كونه مشروعًا رئيسيًا في مؤسسة Apache Software Foundation، جعل APISIX من السهل على المستخدمين العثور على الوثائق التقنية ذات الصلة مقارنة بـ Kong. وجود دعم مجتمع Apache يوفر مساعدة تقنية موثوقة عند مواجهة التحديات، مما يجعل APISIX خيارًا أكثر ملاءمة لشركة الطيران.

بالإضافة إلى ذلك، تعالج APISIX بشكل فعال نقاط الألم المذكورة سابقًا فيما يتعلق بـ NGINX.

• تخزن APISIX التكوينات في etcd، مما يسمح للمطورين بإدارة عقد APISIX متعددة لنطاقات مختلفة بسهولة عن طريق نشر مجموعة etcd واحدة.

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

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

بشكل عام، تبرز APISIX كأكثر المنتجات ملاءمة للفريق التقني.

الانتقال من NGINX إلى APISIX: استكشاف حلول أكثر تقدمًا ولكن أبسط

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

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

فيما يلي مقارنة بين التكوين في NGINX و APISIX.

#   NGINX  conf
    add_header 'Access-Control-Allow-Origin' $corsHost;
    add_header 'Access-Control-Allow-Methods' 'GET,POST,OPTIONS';
    add_header 'Access-Control-Allow-Credentials' 'true';
    add_header 'Access-Control-Allow-Headers' 'DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Accept,Authorization,appver';
    if ($request_method = 'OPTIONS') {
            return 204;
     }

#  APISIX  plugins config
    "cors": {
      "allow_credential": true,
      "allow_headers": "DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Accept,Authorization,appver",
      "allow_methods": "GET,POST,PUT,OPTIONS",
      "allow_origins": "https://wap.test.com,http://wap.test.com,",
    },
    "response-rewrite": {
      "status_code": 204,
      "vars": [
        [
          "request_method",
          "==",
          "OPTIONS"
        ]
      ]
    }

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

الإنجازات

تبسيط إدارة تكوين العقد المتعددة

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

تبسيط العمليات مع إضافات APISIX

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

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

إنشاء بوابة API شاملة

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

إعادة هيكلة التكوينات القديمة إلى وحدات قابلة لإعادة الاستخدام

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

الخلاصة

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

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

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