لماذا اختارت Beike، منصة الإسكان الشهيرة، Apache APISIX

مرحبًا، أنا هوي وانغ، مسؤول عن تطوير نظام بوابة API في Ke Holdings (Beike)، وهي منصة رائدة متكاملة عبر الإنترنت وخارجه لمعاملات وخدمات الإسكان في الصين. تستخدم Beike Apache APISIX كبوابة API في نظام الإنتاج. كشركة تعتمد على البيانات، يمر ملايين من حركة المرور الإنتاجية عبر بوابة API يوميًا، ويمكن لـ Apache APISIX تقديم أداء مستقر ومتميز. مؤخرًا، انضم Apache APISIX إلى حاضنة Apache، وأود أن أغتنم هذه الفرصة لمشاركة السبب وراء اختيارنا لـ Apache APISIX في البداية وبعض الخبرات أثناء استخدامه.

Kong أم Apache APISIX

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

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

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

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

قبل بضعة أيام، تم إصدار الإصدار 0.5 من بوابة API Apache APISIX. بموقف تعليمي، نظرت بسرعة إلى هذا المشروع المفتوح المصدر ووجدت بشكل مفاجئ أن Yuansheng Wang و Ming Wen، خبيران في مجال API، قاما بتطويره معًا. لم أستطع رفض هذا المنتج بناءً على تأييد هؤلاء الخبراء.

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

ومع ذلك، فإن المشكلة الأكثر أهمية هي أن أداء Apache APISIX قد يكون نقطة ضعف بسبب وقت المصدر المفتوح المحدود. بعد مقارنة نتائج اختبار الضغط مع Kong تحت نفس بيئة الاختبار، تفوق Apache APISIX في النهاية على Kong. ومع ذلك، فإن هذا ليس عادلًا لـ Kong حيث أن Kong أثقل بكثير وأكثر تعقيدًا. من ناحية أخرى، لا يوجد فرق في حالتي الاستخدامية حيث يتم توفير جميع الوظائف المطلوبة في Apache APISIX. وفقًا لتقرير اختبار أداء Apache APISIX، يمكن لوحدة المعالجة المركزية ذات النواة الواحدة الوصول إلى 24k QPS، بينما يكون زمن الوصول 0.7 مللي ثانية فقط.

باختصار، اخترت Apache APISIX للأسباب التالية:

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

الأسباب التي قدمها الموقع الرسمي لـ APISIX موضحة في الشكل التالي:

ما هي القدرات التي يمكن أن يوفرها Apache APISIX

• التحديثات الساخنة والإضافات الساخنة
• موازنة الحمل الديناميكية
• الفحص الصحي النشط والسلبي
• قاطع الدائرة
• المصادقة
• الحد من المعدل
• تحويل بروتوكول gRPC
• TCP/UDP الديناميكي، gRPC، WebSocket، وسيط MQTT
• لوحة التحكم
• قائمة المحظورات والمسموح بها
• Serverless

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

قصة كيفية دمجنا APISIX

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

بعد أسبوعين من العمل الجاد، أصبح لدى مشروعي بعض الهياكل الأساسية. حان الوقت لفحص النتيجة؛ وهكذا بدأنا مرحلة اختبار الضغط. يتم نشر الخدمة على Tencent Cloud مع خوادم 8 Core و 32 GB ذاكرة، والعلوي هو بيئة إنتاج سحابية عادية، لذلك لا يمكن اختبارها بقوة كبيرة. تقرير الأداء كما يلي:

ملخص تقرير الأداء: انخفض وقت استهلاك الواجهة بنسبة 47%، ولم يتم رفع أي أخطاء، وتحسنت الاستقرار. زادت قيمة الذروة لـ TPS بنسبة 82%، ولم يتم رفع أي أخطاء، وتحسنت الاستقرار.

بيئة التطوير جاهزة، وبدأنا في دراسة النشر السحابي. يدعم Apache APISIX العديد من طرق التثبيت: Docker، حزمة RPM، Luarocks، والأكواد المصدرية. الخبر السيئ هو أنه لا يُسمح بتثبيت أي شيء في البيئة السحابية، ويمكن وضع الكود المصدر فقط في مسار طريق ثابت. لذلك لن يتم دعم العديد من ميزات Apache APISIX حيث تم تطويرها بناءً على OpenResty 1.15.8. ماذا يمكنني أن أفعل؟ يتم إنشاء الملفات المترجمة في مستودع الكود، ويجب تجميعها تحت بعض الدلائل المحددة، ولا يمكنك استخدام الربط الثابت لـ PCRE، مما كلفنا 1-2 يومًا. أخيرًا، قمنا بضبط الإصدار الرمادي؛ ارتفع حجم المرور من 2% إلى الحجم الكامل خلال عدة أسابيع. لحسن الحظ، نجح كل شيء في النهاية.

بعد عدة أسابيع من المراقبة، أصبحت الخدمة عبر الإنترنت مستقرة نسبيًا. العديد من وظائف Apache APISIX 0.5 يجب تنفيذها من خلال استدعاءات واجهة API. معلمات الطلب عرضة لأخطاء الصياغة، وليس هناك صفحة بديهية ومريحة. بالإضافة إلى ذلك، يحتاج سيناريو أعمالنا إلى وظيفة استكشاف الخدمات العلوية. من قبيل الصدفة، تم إصدار الإصدار 0.7 من Apache APISIX للتو، ويدعم الإصدار 0.7 وحدة التحكم واستكشاف الخدمات العلوية، وهو بالضبط ما نحتاجه الآن. يا له من خبر رائع! يجب أن نقوم بالترقية!

من السهل ترقية فرع Apache APISIX إلى 0.7، ولكن كيف يمكننا دمج الكود؟ التغييرات في الكود بين هذين الإصدارين كبيرة جدًا. أحاول دمجها أولاً، ولكن هناك الكثير من التعارضات، ونحن في وتيرة خطيرة. الطريقة القياسية لحل التعارضات غير واقعية، مما قد يتسبب في الكثير من الأخطاء الخفية. هل هناك أي حل فعال؟ بحثت عبر الإنترنت ووجدت الطرق المختصرة: git checkout –ours و git checkout –theirs (يرجى البحث عنها إذا لم تكن قد استخدمتها)، وأكملت الترقية من APISIX 0.5 إلى 0.7 في بضع دقائق. بالطبع، يجب أيضًا شكر متانة كود APISIX، مما جعلني أحتاج فقط إلى إضافة إضافات الأعمال دون أي اقتران.

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

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

بعد إعادة إطلاق المشروع، يمكن أن يقدم لي الإصدار 0.7 من Apache APISIX مفاجآت من وقت لآخر. الاعتماد على التوجيه المستخدم في الإصدار 0.5 من Apache APISIX كان libr3، بينما استخدم الإصدار 0.7 من Apache APISIX شجرة radix، والتي تعمل بشكل أفضل. انخفضت نسب استخدام وحدة المعالجة المركزية والذاكرة. في الإصدار 0.5 من Apache APISIX، كان استخدام وحدة المعالجة المركزية 1-10%، والذاكرة 0.1%. في الإصدار 0.7 من Apache APISIX، انخفض استخدام وحدة المعالجة المركزية إلى 1-2%، والذاكرة أقل من 0.1%، وهو ممتاز.

الخطة المستقبلية

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

أخيرًا، أود أن أشكر Yuan Sheng و Wen Ming على تقديم مثل هذه المنتجات الرائعة ومجتمع Apache APISIX على الوظائف التكرارية المساهمة. الآن تجاوزت حركة المرور اليومية للبوابة 100 مليون، وليس هناك أي مشكلة في الأداء. شكرًا لوقتك واهتمامك!