استكشافات تقنية لبوابة API مفتوحة المصدر Apache APISIX

الخلفية

Apache APISIX هو بوابة API مفتوحة المصدر ديناميكية، تعمل في الوقت الفعلي، وتتميز بأداء عالي، حيث توفر وظائف غنية لإدارة حركة المرور مثل موازنة الحمل، التوجيه الديناميكي، الإصدار التدريجي (Canary Release)، قطع الدائرة (Circuit Breaking)، المصادقة، وإمكانية المراقبة.

كبوابة API، يمكن لـ Apache APISIX مساعدة الشركات في معالجة حركة مرور API والخدمات المصغرة بسرعة وأمان في سيناريوهات مثل البوابات، Kubernetes Ingress، وشبكات الخدمات (Service Mesh). بالإضافة إلى ذلك، يمكنها التعامل مع حركة المرور من الشمال إلى الجنوب (من العميل إلى الخادم) وحركة المرور من الشرق إلى الغرب (بين الخدمات المصغرة المختلفة داخل الشركة).

تم إصدار APISIX كمشروع مفتوح المصدر في 6 يونيو 2019، وتم التبرع به إلى مؤسسة Apache Software Foundation في أكتوبر 2019، وأصبح بسرعة مشروعًا رئيسيًا في مؤسسة Apache Software Foundation خلال بضعة أشهر.

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

الميزات الرئيسية لـ Apache APISIX

التحرر من الاعتماد على قواعد البيانات

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

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

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

لذلك، حاول مصممو APISIX تجنب مثل هذه المشكلات من جانب البنية التحتية الأساسية.

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

الجزء الثاني يسمى مستوى التحكم. لا يستخدم APISIX تخزين التكوين التقليدي مثل MySQL، بل يستخدم etcd في مستوى التحكم.

مزايا القيام بذلك:

1. أكثر توافقًا مع بنية المنتجات السحابية الأصلية
2. أكثر ملاءمة لأنواع البيانات المخزنة بواسطة بوابة API
3. يعكس بشكل أفضل خصائص التوفيرية العالية
4. إشعارات التغيير في غضون أجزاء من الثانية

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

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

الإضافات (Plugins) للعديد من لغات البرمجة

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

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

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

في الأساس، يحل APISIX المشكلات بطريقتين.

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

من ناحية، هذا مفيد لتقليل تكاليف التطوير وتحسين كفاءة التطوير. ومع ذلك، من ناحية أخرى، هناك بعض التأخير على مستوى الأداء. لذا يطرح السؤال: هل هناك حل يمكن أن يحقق الأداء الأصلي لـ Lua مع مراعاة اللغة عالية المستوى في نفس الوقت؟

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

من خلال تضمين WebAssembly في APISIX، يمكن للمستخدمين استخدامه لتجميع إلى bytecode WebAssembly الذي يعمل في APISIX. التأثير النهائي هو تطوير إضافة APISIX بكفاءة عالية الأداء ومكتوبة بلغات برمجة عالية المستوى.

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

إعادة تحميل الإضافات الساخنة (Hot Reloading)

يتميز APISIX بتقدمين كبيرين مقارنة بـ NGINX: APISIX يدعم إدارة الكتلة وإعادة التحميل الديناميكي.

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

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

• التحديثات الساخنة والإضافات الساخنة: يقوم بتحديث تكويناته وإضافاته باستمرار دون إعادة تشغيل!
• إعادة كتابة الوكيل (Proxy Rewrite): يدعم إعادة كتابة المضيف، URI، المخطط، الطريقة، والعناوين للطلب قبل إرساله إلى upstream.
• إعادة كتابة الاستجابة (Response Rewrite): تعيين رمز حالة الاستجابة المخصص، الجسم، والعناوين للعميل.
• موازنة الحمل الديناميكية: موازنة الحمل بالتناوب مع الأوزان.
• موازنة الحمل القائمة على التجزئة: موازنة الحمل مع جلسات التجزئة المتسقة.
• الفحوصات الصحية (Health Checks): تمكين الفحوصات الصحية على العقدة upstream وسيتم تصفية العقد غير الصحية تلقائيًا أثناء موازنة الحمل لضمان استقرار النظام.
• قطع الدائرة (Circuit-Breaker): تتبع ذكي للخدمات upstream غير الصحية.
• مرآة الوكيل (Proxy Mirror): يوفر القدرة على عكس طلبات العميل.
• تقسيم حركة المرور (Traffic Split): يسمح للمستخدمين بتوجيه نسب مئوية من حركة المرور بين مختلف upstreams.

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

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

التنسيق الديناميكي للإضافات

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

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

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

يحتوي APISIX حاليًا على ما يقرب من 100 إضافة، لكنه يحتوي على أكثر من 100 إمكانية. وبالتالي، بعد تطوير قدرته في ترتيب الإضافات، يصبح التركيب 100 * 99 * 98 * 97 * 96 * ...، قريبًا من اللانهائي.

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

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

بوابة لحركة المرور في جميع الاتجاهات

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

تختلف المكونات في التعامل مع حركة المرور من الشمال إلى الجنوب ومن الشرق إلى الغرب. على سبيل المثال، قد تمر حركة المرور من الشمال إلى الجنوب عبر موازن الحمل، تذهب إلى بوابة API، ثم تدخل بوابة الخدمة. لهذا السبب هناك مكونات مثل NGINX، APISIX، و Spring Cloud Gateway. عند التعامل مع حركة المرور من الشرق إلى الغرب باستخدام شبكة الخدمات، قد تستخدم مكونات مثل Envoy، والتي تبدو كثيرة، ولكن يمكنك العثور على أوجه التشابه إذا ركزت على وظائفها. معظمها عبارة عن إضافات لتوجيه الجدولة، upstream الديناميكي، والمصادقة الآمنة. في هذه الحالة، هل يمكننا توحيد المكونات التي تتعامل مع حركة المرور من الشمال إلى الجنوب ومن الشرق إلى الغرب؟ الطريقة المثالية هي أنه عندما يدخل طلب العميل إلى الخادم، يتم استلامه بالكامل بواسطة APISIX. بغض النظر عن الشمال إلى الجنوب أو الشرق إلى الغرب، يتم التحكم في كل حركة المرور والبيانات من خلال مستوى التحكم. يمكن تحقيق ذلك تمامًا باستخدام التكنولوجيا الحالية لـ APISIX.

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

دعم مكونات اكتشاف الخدمات المتعددة

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

مكون آخر أساسي - اكتشاف الخدمات والتسجيل سيتم استخدامه في التكامل مع العناصر الأخرى. سيضع المستخدمون الخدمات المختلفة في أجزاء منفصلة، مثل Eureka و Nacos. وبالتالي، من الشائع أن تتعايش مكونات اكتشاف الخدمات المتعددة في أنظمة تكنولوجيا المعلومات الكبيرة والعمر الطويل.

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

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

استكشاف سيناريوهات السحابة المتعددة والسحابة الهجينة

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

1. دعم كل من Upstream و Downstream لـ mTLS

لم نكن ندرك أن دعم وظيفة mTLS لـ upstream كان أولوية عالية سابقًا. ومع ذلك، بمجرد أن تكون في سيناريو عبر السحابة، قد يكون upstream خدمة على سحابة أخرى أو حتى يصبح خدمة SaaS أخرى. وبالتالي، من الضروري دعم mTLS لـ upstream لتحسين أمان البيانات.

2. الفصل الكامل بين بنية مستوى التحكم ومستوى البيانات

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

3. تعزيز إدارة الأمان

تخزن البوابة بشكل عام بعض البيانات الحساسة. على سبيل المثال، قد يحتفظ بعض المستخدمين بشهادة SSL أو المعلومات الحرجة للاتصال بـ etcd على البوابة. في مثل هذه الظروف، بمجرد اختراق etcd أو مستوى البيانات، قد يتسبب ذلك في تسرب بيانات خطير. لذلك، عند تخزين بعض المعلومات الأساسية، من الضروري النظر في استخدام مكون مخصص لتخزين المفاتيح مثل Vault لحماية البيانات الحساسة.

4. دمج المزيد من معايير السحابة

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

داعمو Apache APISIX

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

يجب أن يُعزى التكرار والترقية لمنتج مفتوح المصدر إلى المساهمين والمستخدمين.

عندما تم التبرع بـ APISIX إلى مؤسسة Apache Software Foundation قبل ثلاث سنوات، كان مشروعًا غير ناضج مع 20 مساهمًا فقط. لحسن الحظ، جذب APISIX المزيد من المستخدمين والمساهمين والشركات في جميع أنحاء العالم بفضل تطوره السريع. على سبيل المثال، تشمل عملائنا شركات مثل Tencent، WPS، Sina Weibo، و iQiyi، حيث تحمل عشرات المليارات من استدعاءات API يوميًا. علاوة على ذلك، العديد من المستخدمين الدوليين من مختلف الصناعات، مثل NASA، European Factory Platform، Swisscom، إلخ، هم من بين قائمة عملائنا.

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

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

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

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

معاينة APISIX 3.0

حتى الآن، تحدثنا كثيرًا عما فعله APISIX في الماضي والحاضر. يمكن تقسيم عملية تطوير APISIX إلى عدة مراحل.

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

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

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

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

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

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

مستقبل APISIX

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

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

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

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