لماذا يُعتبر Apache APISIX أفضل بوابة API؟

في الوقت الحاضر، تُستخدم الهواتف المحمولة في جميع أنواع الأشياء، وتتوفر تطبيقات متنوعة على متجر التطبيقات بما في ذلك وسائل التواصل الاجتماعي، التطبيقات المساعدة، الألعاب، نمط الحياة، التسوق عبر الإنترنت، وغيرها. بناء هذه التطبيقات لا ينفصل عن واجهات برمجة التطبيقات (APIs). لذلك، يجب على الشركات التي تقدم خدمات من خلال واجهات برمجة التطبيقات اختيار بوابة واجهات برمجة التطبيقات (API Gateway) موثوقة لضمان سرعة خدماتها، استقرارها، وأمانها.

في منظر بوابة واجهات برمجة التطبيقات من CNCF، هناك ما يقرب من 20 نوعًا من بوابات واجهات برمجة التطبيقات (لا تشمل خدمات بائعي السحابة)، بما في ذلك Apache APISIX، Kong، Tyk، وغيرها. العديد منها تدعي أنها الأكثر شعبية بين مشاريع بوابات واجهات برمجة التطبيقات مفتوحة المصدر، أو أنها بوابة واجهات برمجة التطبيقات من الجيل التالي، ولكن هل هذا صحيح؟

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

مهندسو البرمجيات يعرفونها جيدًا

مهندسو البرمجيات هم المستخدمون والمطورون لواجهات برمجة التطبيقات وبوابات واجهات برمجة التطبيقات، لذا فإن شعبيتها بين المهندسين هي مؤشر مباشر على الاتجاه. أدناه رسم بياني يقارن إجمالي عدد المساهمين في GitHub لأربع بوابات واجهات برمجة التطبيقات: Apache APISIX، Kong، Tyk، وGloo.

يمكننا أن نرى من الرسم البياني أن كلًا من Kong وTyk بدأوا حوالي عام 2015، بينما بدأ Apache APISIX وGloo لاحقًا في عام 2019. الأهم من ذلك، يمكننا أيضًا أن نرى أن Apache APISIX الأصغر لديه أشد منحنى بينهم جميعًا وقد جمع أكثر من 320 مساهمًا، متجاوزًا Kong الذي يحتل المركز الثاني بـ 57 شخصًا، ليصبح مشروع بوابة واجهات برمجة التطبيقات الذي لديه أكبر عدد من المساهمين.

بالإضافة إلى إجمالي عدد المساهمين، فإن عدد المساهمين النشطين شهريًا يشير إلى أهمية أكبر. كان عدد المساهمين النشطين شهريًا لـ Tyk حوالي 5 فقط ونادرًا ما يتجاوز 10، بينما كان Kong وGloo يتأرجحان بين 10 و20. في الوقت نفسه، كان لدى Apache APISIX مساهمون نشطون شهريًا فوق 20 بشكل مستقر، وقرابة 40 في الذروة، مما يجعله مشروع بوابة واجهات برمجة التطبيقات الأكثر نشاطًا.

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

اعتبارًا من عام 2022، كانت نسبة Kong وTyk 4%، وكانت نسبة Gloo 24%. في المقابل، وصلت APISIX تقريبًا إلى 100%. السبب وراء ذلك هو أنه منذ البداية عندما بدأت شركة API7.ai مشروع APISIX، كانت تضع جهودًا مستمرة في المجتمع المفتوح المصدر وحصلت على سمعتها بين المطورين.

ترخيص المصدر المفتوح: العامل الأهم في اختيار بوابة واجهات برمجة التطبيقات مفتوحة المصدر

منذ أن غيرت MongoDB ترخيصها المفتوح المصدر إلى SSPL (Server Side Public License) في عام 2018، أصبح على الشركات أن تفتح مصدرها الخاص عندما يتم استخدام MongoDB كخدمة مدارة. نتيجة لذلك، تحتاج الشركات إلى أخذ ترخيص المصدر المفتوح للمشروع في الاعتبار بجدية عند اختيار مشروع.

من الناحية السطحية، تستخدم Apache APISIX، Kong، وGloo جميعها ترخيص Apache License Version 2.0 الصديق للتجارة، بينما تستخدم Tyk ترخيص Mozilla Public License Version 2.0. ولكن عند التعمق أكثر، نجد أن Kong، Gloo، وTky مدعومون جميعًا من قبل بائعي المصدر المفتوح التجاريين. يمكنهم تغيير ترخيصهم في أي وقت مثل MongoDB، مما يحد من استخدامه بحرية من قبل السحابة العامة أو الشركات الأخرى، ويجبرك على الدفع للوصول إلى الإصدارات الجديدة.

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

في مثل هذه الظروف، اختيار مشروع مفتوح المصدر من مؤسسة Apache Software Foundation (ASF) أو مشروع مفتوح المصدر من CNCF هو الخيار الأفضل، لأنه لا يمكن تعديل ترخيص المشروع. Apache APISIX هو مثل هذا المشروع. إنه مشروع من المستوى الأعلى في ASF، مما يعني أنه لا توجد شركة تجارية لديها سيطرة مطلقة على مشروع Apache APISIX، جميع الأكواد مملوكة لـ ASF ولن يتم تغيير الترخيص. يمكن للمستخدمين الشركات استخدامه بحرية دون القلق من تلقي رسائل استفسار من المحامين وإدارات الامتثال.

أداء Apache APISIX، Kong، وGloo

سؤال متكرر في المجتمع: أي منهما لديه أداء أفضل، Gloo القائم على Envoy أم APISIX القائم على NGINX؟ على الرغم من أن الأداء ليس المقياس الأكثر أهمية، إلا أنه بلا شك المقياس الأكثر مباشرة. الجدول أدناه يظهر نتائج اختبار الأداء لـ Apache APISIX وGloo. QPS لـ Apache APISIX هو 4.6 أضعاف Gloo، وزمن الاستجابة لـ Apache APISIX هو 7% فقط من Gloo.

اختيار NGINX أو Envoy ليس العامل الرئيسي في اختلاف الأداء، ولكن التحسينات الأساسية التي قام بها APISIX في الكود المصدري. حتى مقارنة بـ KONG، الذي يعتمد أيضًا على NGINX، فإن APISIX لديه ميزة أداء كبيرة. الرسم البياني أدناه مأخوذ من تقرير GigaOm حول اختبار الإصدار المؤسسي لـ Kong والإصدار المؤسسي لـ AP7 (يمكنك الاتصال بنا للحصول على البيانات الكاملة).

زمن الاستجابة لـ Kong هو عشرات أو حتى مئات المرات من زمن استجابة API7 (الإصدار المؤسسي الذي أنشأه مؤلفو Apache APISIX).

لماذا لدى APISIX ميزة أداء كبيرة؟ لا توجد أسرار أمام الكود.

الكلام رخيص، أرني الكود

الآن، دعونا نحلل Apache APISIX، Kong، وGloo من وجهة نظر تقنية. تعتمد ميزة Apache APISIX في الغالب على التحسين والابتكار في الكود المصدري. مزايا هذه التقنيات لا تنعكس بالضرورة في PoC (Proof of Concept) البسيط، ولكنها تظهر في بيئة إنتاج أكثر تعقيدًا.

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

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

لتقليل الضرر، قام APISIX ببناء بنيته لتجنب إمكانية التوقف وفقدان البيانات. استخدم APISIX etcd لتخزين بيانات التكوين بدلاً من قاعدة بيانات علائقية، ومزايا ذلك هي كما يلي:

1. إنه أكثر توافقًا مع بنية السحابة الأصلية
2. إنه تمثيل أفضل لنوع البيانات المطلوبة لبوابة واجهات برمجة التطبيقات
3. سيكون لديه توفر أعلى
4. يمكن إخطار التغييرات على مستوى أقل من المللي ثانية

بعد استخدام etcd لتخزين بيانات التكوين، يحتاج المستخدمون فقط إلى مراقبة تحديثات etcd لتغييرات البيانات. سيتمكن APISIX من الحصول على أحدث تكوين في غضون مللي ثوانٍ، مما يحقق تأثيرًا في الوقت الفعلي. إذا كنا نستعلم من قاعدة البيانات، فقد يستغرق الأمر 5-10 ثوانٍ للحصول على أحدث معلومات التكوين. لذلك، فإن استخدام etcd كخطة تخزين لا يجعل APISIX أكثر توافقًا مع السحابة الأصلية فحسب، بل أيضًا أكثر توفرًا.

خوارزمية مطابقة المسارات عالية الأداء

لمعالجة طلب، تحتاج بوابة واجهات برمجة التطبيقات إلى مطابقة التعبير الهدف مع معلومات المضيف، URI، طرق HTTP، وغيرها من المعلومات لكل طلب. وبالتالي، فإن خوارزمية مطابقة فعالة أمر بالغ الأهمية. الخوارزمية القائمة على التجزئة لديها أداء جيد، ولكن لا يمكنها تحقيق المطابقة الضبابية. التعبيرات العادية يمكنها إجراء مطابقة ضبابية، ولكن الأداء ليس جيدًا. حل Apache APISIX هو استخدام شجرة، وهي بنية بيانات بحث فعالة تدعم المطابقة الضبابية. على وجه التحديد، يستخدم Apache APISIX شجرة radix (شجرة بادئة مضغوطة)، وهي بنية بيانات تضغط فقط العقد الوسيطة التي لديها طفل واحد. من بين جميع منتجات بوابات واجهات برمجة التطبيقات المعروفة، Apache APISIX هو الأول الذي يطبق شجرة radix في مطابقة المسارات ويدعم السيناريو حيث يمكن لبادئة واحدة أن تطابق عدة مسارات. للتفاصيل التنفيذية، انظر lua-resty-radixtree.

عند مطابقة طلب، ستقوم الخوارزمية مع شجرة radix بمطابقته تدريجيًا، مع تعقيد O(K) (K هو طول URI في المسار، وهو مستقل عن عدد واجهات برمجة التطبيقات). هذه الخوارزمية مناسبة جدًا في السيناريوهات التي يوجد فيها عدد كبير من المسارات، مثل السحابة العامة أو CDN. كما أنها لا تواجه مشكلة في التعامل مع عدد كبير من المسارات التي تزداد بسرعة.

خوارزمية مطابقة IP عالية الأداء

عنوان IP له طريقتان للتدوين: التدوين القياسي لـ IP وتدوين CIDR، على سبيل المثال IPv4 32-bit:

• التدوين القياسي لـ IP: 192.168.1.1
• تدوين CIDR: 192.168.1.1/8

تستخدم Apache APISIX خوارزميات مختلفة لمطابقة IP ومطابقة المسارات. خذ عنوان IP 192.168.1.1 كمثال، نظرًا لأن نطاق كل جزء من IP هو من 0 إلى 255، يمكننا التفكير في أن عنوان IP يتكون من أربعة أعداد صحيحة 16-bit، وطول IP ثابت. وبالتالي، يمكننا استخدام خوارزمية أكثر كفاءة لإكمال المطابقة.

افترض أن هناك مكتبة IP تحتوي على 500 سجل IPv4، سيتم تخزين هذه السجلات في جدول التجزئة، واستخدام جدول التجزئة لمطابقة IP. تعقيد الوقت هو O(1). تقوم بوابات واجهات برمجة التطبيقات الأخرى بإكمال مطابقة IP من خلال التكرار عبر القائمة، وقد يتم تكرار كل طلب يرسل إلى البوابة حتى 500 مرة. لذلك، تحسن خوارزمية مطابقة IP عالية الدقة في APISIX كفاءة السيناريوهات التي تتطلب مطابقة قوائم السماح والرفض الضخمة (مثل WAF).

تحسين المسارات

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

أولاً، يدعم Apache APISIX المتغيرات المضمنة في NGINX، مما يعني أنه يمكننا استخدام عشرات المتغيرات المضمنة في NGINX كمعلمات مطابقة، بما في ذلك uri، server_name، server_addr، request_uri، remote_port، remote_addr، query_string، host، hostname، arg_name.

للقائمة الكاملة للمتغيرات المضمنة في NGINX، انظر متغيرات NGINX.

ثانيًا، يدعم Apache APISIX التعبيرات الشرطية كقواعد مطابقة، وبنيتها هي [var, operator, val], ...]]، حيث:

• يمكن أن تكون قيم var متغيرات NGINX المضمنة.
• يدعم operator التساوي، أكبر من، أقل من، التعبيرات العادية، يحتوي، إلخ.

افترض أن التعبير هو ["arg_name", "==", "json"]، فهذا يعني ما إذا كانت هناك قيمة معلمة name تساوي json في معلمات استعلام URI للطلب الحالي. يقوم Apache APISIX بتنفيذ هذه الميزة من خلال مكتبته lua-resty-expr. للتفاصيل، يرجى الرجوع إلى lua-resty-expr. هذه الميزة تعطي المستخدم الكثير من المرونة وهي قابلة للتوسيع بشكل كبير.

بالإضافة إلى ذلك، يسمح Apache APISIX للمستخدمين بإعداد ttl (وقت البقاء) للمسارات.

$ curl http://127.0.0.1:9080/apisix/admin/routes/2?ttl=60 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -i -d '
{
    "uri": "/aa/index.html",
    "upstream": {
        "type": "roundrobin",
        "nodes": {
            "39.97.63.215:80": 1
        }
    }
}'

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

أخيرًا، يدعم Apache APISIX وظائف التصفية المخصصة، حيث يمكن للمرء كتابة وظائف Lua مخصصة في معلمة filter_func، على سبيل المثال:

$ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -i -d '
{
    "uri": "/index.html",
    "hosts": ["foo.com", "*.bar.com"],
    "filter_func": "function(vars)
                    return vars['host'] == 'api7.ai'
                end",
    "upstream": {
        "type": "roundrobin",
        "nodes": {
            "127.0.0.1:1980": 1
        }
    }
}'

معلمة الإدخال لـ filter_func هي vars، ويمكن الحصول على متغيرات NGINX من vars، ومن ثم يمكن تخصيص منطق التصفية.

دعم الإضافات متعددة اللغات

غالبًا ما يحتاج المستخدمون إلى تخصيص بعض التطوير وتكامل النظام لبوابة واجهات برمجة التطبيقات تجاه سيناريوهات محددة.

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

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

ردًا على هذه الحالة، يوفر APISIX حلين.

الحل الأول هو دعم المزيد من لغات البرمجة الرئيسية (مثل Java، Python، Go، إلخ) من خلال Plugin Runner. باستخدام Plugin Runner، يمكن لمهندسي الخلفية التواصل من خلال RPC المحلي لتطوير إضافات APISIX باستخدام لغات البرمجة التي يعرفونها. ميزة هذا هي تقليل تكاليف التطوير وتحسين كفاءة التطوير. العيب سيكون خسائر الأداء. لذا، هل هناك طريقة لتحقيق أداء قريب من الأداء الأصلي لـ Lua باستخدام لغات عالية المستوى يعرفها المطورون؟

الحل الثاني هو استخدام Wasm لتطوير الإضافات، كما هو موضح في الجزء الأيسر من الشكل أعلاه. Wasm (WebAssembly) تم استخدامه في البداية كتقنية جديدة تعمل في المتصفحات، ولكنه الآن يظهر أيضًا مزاياه على جانب الخادم. قمنا بتضمين Wasm في APISIX، ويمكن للمستخدمين استخدام Wasm لتجميع bytecode Wasm لتشغيله في APISIX. للاستفادة من Wasm قمنا بتطوير إضافة Wasm حيث يمكن للمستخدمين تطوير إضافات APISIX قريبة من الأداء الأصلي باستخدام لغات البرمجة عالية المستوى.

نتيجة لذلك، يمكن للمستخدمين استخدام Lua، Go، Java، Python، Node.js، وWasm لكتابة إضافات مخصصة على APISIX. بجعل التطوير سهلًا، يفتح الأبواب لتطوير إضافات APISIX.

الخلاصة

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

Apache APISIX ليست فقط بوابة واجهات برمجة التطبيقات التي يمكنها التعامل مع حركة المرور الشمالية-الجنوبية، ولكن لديها أيضًا منتجات مفتوحة المصدر مثل APISIX Ingress Controller وService Mesh.

كما توفر منتجات مؤسسية ومنتجات SaaS قائمة على APISIX.

جرب Apache APISIX ومنتجات API7 المؤسسية اليوم!