أداء بوابات API مفتوحة المصدر: APISIX 3.0 و Kong 3.0

الخلفية

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

في خريف عام 2022، أصدرت Apache APISIX و Kong إصدار 3.0 في نفس الوقت تقريبًا. على وجه الخصوص، تركز ميزات Apache APISIX 3.0 الجديدة على النظام البيئي، الذكاء، والتطبيقات. يمكنك الاطلاع على Apache APISIX 3.0: 11 نقطة بارزة في بوابة API مفتوحة المصدر لمعرفة المزيد.

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

طريقة الاختبار

طوبولوجيا الطلبات

فيما يلي مخطط طوبولوجيا طلبات الاختبار. تم استخدام أداة اختبار الضغط wrk2، وتم استخدام خدمة المنبع OpenResty.

APISIX

Kong

معلومات الخادم

تم إجراء هذا الاختبار على خادم سحابي من نوع Standard D8s v3 (8 vcpu، 32 GiB ذاكرة). تم نشر جميع المكونات المتعلقة بالاختبار على هذا الخادم.

بيئة الخادم

إصدارات البرامج

فيما يلي إصدارات البرامج المستخدمة في هذا الاختبار:

إعدادات الشبكة

عند نشر APISIX و Kong في docker، استخدمنا وضع شبكة المضيف في docker لتجنب تأثيرات الشبكة التي قد تؤثر على نتائج الاختبار.

النشر

اخترنا wrk2 كأداة اختبار معيارية و OpenResty كمنبع محاكاة. قمنا بنشر APISIX و Kong في docker مع تمكين التكوين التصريحي لكليهما.

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

أيضًا، تم إيقاف تشغيل إضافتي proxy-cache و proxy-mirror في APISIX، والتي تم ذكرها في الوثائق المتعلقة بالاختبارات المعيارية في مشروع APISIX (ستؤثر إضافتي proxy-cache و proxy-mirror على أداء APISIX بحوالي 4%).

يمكنك الاطلاع على نص النشر ومرجع نص الاختبار هنا.

الاختبارات

الاختبار #1: مسار واحد

اختبار سيناريو الوكيل النقي. سنستخدم مسارًا واحدًا فقط وبدون إضافات لاختبار أداء APISIX و Kong.

تكوين APISIX:

routes:
  -
    uri: /hello
    upstream:
      nodes:
        "127.0.0.1:1980": 1
      type: roundrobin
#END

تكوين Kong:

_format_version: "3.0"
_transform: true

services:
- name: hello
  url: http://127.0.0.1:1980
  routes:
  - name: hello
    paths:
    - /hello

مقارنة الأداء

استخدمنا مقياس QPS لقياس الأداء. تم إجراء 10 جولات من الاختبار.

كما نرى من الرسم البياني، في سيناريو الوكيل النقي، يكون أداء APISIX 3.0 أعلى بكثير من Kong 3.0. متوسط QPS لـ APISIX 3.0 في 10 جولات هو 14104، ومتوسط QPS لـ Kong 3.0 في 10 جولات هو 9857. أداء APISIX 3.0 هو 140% من Kong 3.0.

الاختبار #2: مسار واحد + إضافة تحديد معدل واحدة

تحديد المعدل هو أحد السيناريوهات الأساسية للمستخدمين في بوابات API. لذا، في هذا السيناريو، قمنا بتكوين البوابات بمسار واحد وإضافة تحديد معدل واحدة.

تكوين APISIX:

routes:
  -
    uri: /hello
    upstream:
      nodes:
        "127.0.0.1:1980": 1
      type: roundrobin
    plugins:
      limit-count:
        count: 999999999
        time_window: 60
        rejected_code: 503
        key: remote_addr
#END

تكوين Kong:

_format_version: "3.0"
_transform: true

services:
- name: hello
  url: http://127.0.0.1:1980
  routes:
  - name: hello
    paths:
    - /hello
    plugins:
    - name: rate-limiting
      config:
        minute: 999999999
        limit_by: ip
        policy: local

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

مقارنة الأداء

مرة أخرى، قمنا بإجراء 10 جولات من الاختبار. نرى من الرسم البياني أنه بعد تمكين إضافة تحديد المعدل، انخفض QPS لكل من APISIX 3.0 و Kong 3.0 بشكل ملحوظ، ولكن انخفض QPS لـ Kong 3.0 بشكل أكبر. متوسط QPS لـ APISIX 3.0 في 10 جولات هو 9154، ومتوسط QPS لـ Kong 3.0 في 10 جولات هو 4810. في هذا السيناريو، أداء APISIX 3.0 هو 190% من Kong 3.0.

الاختبار #3: مسار واحد + إضافة تحديد معدل واحدة + إضافة مصادقة واحدة

المصادقة هي سيناريو شائع آخر لبوابات API.

في هذا السيناريو، قمنا بتكوين البوابات بمسار واحد، إضافة تحديد معدل واحدة، وإضافة مصادقة واحدة.

تكوين APISIX:

routes:
  -
    uri: /hello
    upstream:
      nodes:
        "127.0.0.1:1980": 1
      type: roundrobin
    plugins:
      key-auth:
      limit-count:
        count: 999999999
        time_window: 60
        rejected_code: 503
        key: remote_addr
consumers:
  - username: jack
    plugins:
        key-auth:
            key: user-key
#END

تكوين Kong:

_format_version: "3.0"
_transform: true

services:
- name: hello
  url: http://127.0.0.1:1980
  routes:
  - name: hello
    paths:
    - /hello
    plugins:
    - name: rate-limiting
      config:
        minute: 999999999
        limit_by: ip
        policy: local
    - name: key-auth
      config:
        key_names:
          - apikey
consumers:
- username: my-user
  keyauth_credentials:
  - key: my-key

يغطي هذا السيناريو تحديد المعدل والمصادقة بحيث تعمل إضافات متعددة معًا في مسار الطلب. إنه سيناريو نموذجي يستخدم بوابة API.

مقارنة الأداء

مرة أخرى، قمنا بإجراء عشر جولات من الاختبار لقياس QPS.

نرى من الرسم البياني أنه بعد تمكين إضافتي limit-count و key-auth في APISIX، متوسط QPS لـ APISIX 3.0 هو 8933، وهو أقل قليلاً من متوسط QPS البالغ 9154 عند تمكين إضافة limit-count فقط.

في Kong 3.0، انخفض متوسط QPS إلى 3977، وهو انخفاض كبير مقارنة بمتوسط QPS البالغ 4810 عند تمكين إضافة rate-limiting فقط.

في هذا السيناريو من تمكين إضافات تحديد المعدل والمصادقة، أداء APISIX 3.0 هو 220% من Kong 3.0.

الاختبار #4: 5000 مسار

يستخدم هذا الاختبار نصوصًا لإنشاء 5000 مسار فريد. يقيس الاختبار أداء APISIX و Kong في مطابقة المسارات: مدى سرعة الوصول إلى تطابق.

مقارنة الأداء

في 10 جولات من الاختبار، متوسط QPS لـ APISIX 3.0 هو 13787، ومتوسط Kong 3.0 هو 9840. أداء APISIX 3.0 هو 140% من Kong 3.0.

الخلاصة

من نتائج اختبارات السيناريوهات المتعددة، يتضح أن:

• أداء APISIX 3.0 هو حوالي 140% من Kong 3.0 عند عدم استخدام الإضافات (الاختبار #1 والاختبار #4).
• أداء APISIX 3.0 هو حوالي 200% من Kong 3.0 عند استخدام الإضافات (الاختبار #2 والاختبار #3)

يمكننا أن نرى أن APISIX يحافظ على ميزة أداء كبيرة في إصدار 3.0.