Apache APISIX 3.0: 11 ميزات بارزة في بوابة API مفتوحة المصدر

بوابة API مفتوحة المصدر Apache APISIX الإصدار 3.0 قادم! لقد اخترنا 11 ميزة أساسية لإعطاء نظرة عامة مختصرة.

بوابة API كانت مكونًا أساسيًا لفترة طويلة. كانت ملتزمة بتوفير وظائف مختلفة مثل الحد من المعدل، المصادقة (مثل استخدام Keycloak لتأمين APIs)، والقدرة على المراقبة على مستوى الأعمال.

بوابة API Apache APISIX

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

لذلك، في التصميم المعماري لـ APISIX، يتم فصل مستوى البيانات ومستوى التحكم لتحقيق الديناميكية الكاملة وإدارة الكتلة، والتي يتم تحقيقها بشكل رئيسي من خلال مكونات etcd.

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

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

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

في APISIX، يتم تطوير البرامج المساعدة بشكل رئيسي من خلال Lua، ويتم استخدام LuaJIT (مترجم Just-In-Time لـ Lua) لضمان أن أداء الكود المترجم جيد بما فيه الكفاية.

إذا لم تكن معتادًا على Lua، يمكنك استخدام Plugin Runner، وتطوير برامج APISIX المساعدة باستخدام لغات البرمجة التي تعرفها. كما قمنا بتضمين Wasm في APISIX، ويمكنك استخدام Wasm لتجميع bytecode Wasm لتشغيله في APISIX. نتيجة لذلك، يمكن للمستخدمين استخدام Lua، Go، Python، Wasm، إلخ، لإنشاء برامج مساعدة مخصصة على APISIX.

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

11 ميزة جديدة في APISIX 3.0

قدم APISIX خارطة طريق جديدة للإصدار 3.0 في أوائل عام 2022. في الإصدار 3.0، ستركز التكرارات والتحديثات على قابلية الاستخدام والنظام البيئي.

تم إصدار APISIX 3.0 رسميًا في أواخر أكتوبر 2022. دعونا نلقي نظرة عامة على الميزات الجديدة المثيرة!

1. الدعم الكامل لـ ARM64

أصبح ARM64 اختيارًا شائعًا جدًا لبنية الخادم لدى مصنعي السحابة. من AWS Graviton، GCP Tau T2A إلى Huawei Kunpeng ومنتجات أخرى، يمكننا أن نرى أن مصنعي السحابة المختلفين بدأوا في إطلاق خوادم تعتمد على بنية Arm. يوضح الرسم البياني التالي أداء اختبار الضغط لـ APISIX على الخوادم الشهيرة القائمة على Arm:

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

2. مستوى الذكاء الاصطناعي (AI Plane)

أضاف Apache APISIX مستوى الذكاء الاصطناعي في الإصدار 3.0، مما يحسن الأداء بنسبة 30% (تم قياسه بواسطة QPS تحت اختبار الضغط). سيقوم مستوى الذكاء الاصطناعي بتحسين تكوين مستوى البيانات بشكل ديناميكي، مستفيدًا من البيانات الشاملة مثل إعدادات المستخدمين على المسارات والبرامج المساعدة، بالإضافة إلى مقاييس السجلات. على سبيل المثال، يمكن تحسين السيناريوهات الثلاثة التالية تلقائيًا بواسطة مستوى الذكاء الاصطناعي:

1. عندما يكون مطلب المطابقة بسيطًا (مثل احتواء uri أو host فقط)، يتم تمكين التخزين المؤقت لتسريع عملية مطابقة المسار.
2. إذا لم يكن هناك برنامج مساعد، يتم تشغيل الكود المتعلق بالمصدر العلوي فقط.
3. إذا كان هناك عقدة مصدر علوي واحدة فقط ولم يتم تمكين أي خيار تكوين آخر، يتم تكوين المصدر العلوي بطريقة خفيفة الوزن.

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

3. إضافة عميل gRPC

في الإصدار 3.0، سيدعم Apache APISIX وحدة core.grpc جديدة. ومع ذلك، إذا كنت معتادًا على NGINX وOpenResty، فستعرف أن دعمهما لـ gRPC محدود جدًا، حيث يوفر فقط ميزات أساسية مثل الوكيل العكسي أو موازنة الحمل.

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

4. إعادة تصميم واجهة برمجة التطبيقات الإدارية (Admin API)

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

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

5. فصل مستوى البيانات (DP) ومستوى التحكم (CP)

عانى APISIX من عدة ثغرات أمنية في العامين الماضيين. السبب الجذري لمعظم الثغرات هو أن DP وCP يتم نشرهما معًا في وضع النشر الافتراضي. لذلك، بمجرد وجود ثغرة أمنية على مستوى البيانات، يمكن للمهاجم اختراق CP مباشرة من خلال DP، مما يؤثر على جميع DPs الأخرى.

لذلك، في الإصدار 3.0، يتم دعم وضع النشر التكوين، ووضع النشر الافتراضي هو traditional، حيث يتم نشر DP وCP معًا. بالطبع، يوصي وضع النشر الجديد بتعيين السمة إلى data_plane أو control_plane لفصلهما.

عندما يتم فصلهما، لا يمكن فقط حل المخاطر الأمنية المذكورة أعلاه، ولكن أيضًا تصبح التكرارات الوظيفية على DP وCP أكثر قابلية للإدارة دون التأثير على بعضها البعض.

6. تحسين دعم اكتشاف الخدمة

في الإصدار الحالي، يدعم APISIX تكامل العديد من مكونات اكتشاف الخدمة، مثل Apache ZooKeeper، Consul، Nacos، وما إلى ذلك. ولكن في الوقت الحالي، يتم تنفيذ هذه التكاملات جميعًا على مستوى البيانات. بمجرد وجود الكثير من العقد على DP، سيضع ذلك ضغطًا كبيرًا على مكونات اكتشاف الخدمة التالية. في الوقت نفسه، في بيئة الإنتاج الفعلية للمستخدمين، يريدون تكاملًا بسيطًا مثل Consul KV أو تكامل DNS وتكاملًا كاملاً لوظائف مثل الفحوصات الصحية.

لذلك، في APISIX 3.0، أضفنا طبقة تجريد من خلال إضافة مشروع فرعي APISIX-SEED لتحقيق دعم اكتشاف الخدمة على مستوى التحكم وتقليل الضغط على مكون اكتشاف الخدمة.

7. إضافة إطار عمل xRPC

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

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

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

8. دعم المزيد من القدرة على المراقبة على بروتوكولات طبقة النقل

استثمر APISIX دائمًا بشكل كبير في دعم القدرة على المراقبة، حيث يدعم تقريبًا جميع مكونات القدرة على المراقبة، مثل Zipkin، Apache SkyWalking، Datadog، والمزيد. كما يتم دعم العديد من مكونات التسجيل، ولكن معظمها يتم تنفيذه في طبقة التطبيق.

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

9. تكامل مع مواصفات OpenAPI

API هو عنصر يغطي دورة حياة التطوير بأكملها، من التصميم إلى الترميز، والاختبار، والنشر. في APISIX 3.0، سيدعم Apache APISIX مواصفات OpenAPI 3.0 القياسية.

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

بالإضافة إلى ذلك، يدعم APISIX 3.0 أيضًا تنسيقات Postman المخصصة (Postman Collection Format v2)، مما يمكن نقل البيانات بين الاثنين، مما يجعل التكامل أسهل.

10. الدعم الكامل لـ Gateway API و Service Mesh

بدأ دعم Gateway API في APISIX Ingress Controller، ويتم دعم جميع تكوينات Gateway API تقريبًا في الإصدار الأخير 1.5.

في هذه الحالة، يمكن تكوين APISIX Ingress باستخدام Gateway API، مما يعني أنه يمكنك التبديل بين مستويات بيانات مختلفة. بحلول نهاية هذا العام، سيكون لدى APISIX Ingress دعم كامل لـ Gateway API وميزات إضافية لطبقة النقل والتطبيق.

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

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

11. التكامل مع المزيد من النظم البيئية

بالإضافة إلى معيار OpenAPI المذكور أعلاه، سيتم إضافة العديد من البرامج المساعدة للنظام البيئي في الإصدار 3.0، مثل OpenFunction، ClickHouse، Elasticsearch، SAML، CAS، إلخ، لدمج المزيد من الدعم للمصادقة، الأمان، والقدرة على المراقبة.

أحد البرامج المساعدة المثيرة، workflow، يستخدم لجدولة حركة المرور: يمكننا القيام ببعض المعالجة الدقيقة على مستوى التحكم في حركة المرور.

curl http://127.0.0.1:9180/apisix/admin/routes/1 \
-H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
  "uri":"/hello/*",
  "plugins":{
    "workflow":{
      "rules":[
        {
          "case": [
            ["uri", "==", "/hello/rejected"]
          ],
          "actions": [
            [
              "return",
              {"code": 403}
            ]
          ]
        },
        {
          "case": [
            ["uri", "==", "/hello/v2/appid"]
          ],
          "actions": [
            [
              "limit-count",
              {
                "count": 2,
                "time_window": 60,
                "rejected_code": 429
              }
            ]
          ]
        }
      ]
    }
  },
  "upstream": {
    "type": "roundrobin",
    "nodes": {
      "127.0.0.1:1980": 1
    }
  }
}'

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

البدء مع Apache APISIX 3.0

يمكنك الآن التحقق من APISIX 3.0 على صفحة الإصدار على GitHub وصفحة التنزيل!

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

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