كيفية تنفيذ تنسيق الإضافات (Plugin Orchestration) في بوابة واجهة برمجة التطبيقات (API Gateway)

شاهد الفيديو

دعني أولاً أقدم نفسي. أنا مينغ وين، المؤسس المشارك لـ API7.ai. أنا نائب الرئيس وعضو لجنة إدارة المشروع (PMC) في المشروع المفتوح المصدر Apache APISIX. كما أنني مساهم في Apache SkyWalking. بالإضافة إلى ذلك، أنا مؤسس لجنة المصادر المفتوحة في Qihoo 360، وخبير تلفزيوني في Tencent Cloud (TVP)، وعضو في لجنة التوجيه الفني (TOC) في مؤسسة TARS. لدي أكثر من 40 براءة اختراع في مجال الأمان.

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

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

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

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

لذا دعونا نلقي نظرة على ما يمكن أن يفعله Apache APISIX لك؟ يمكنه التعامل مع حركة المرور في الطبقة الرابعة والطبقة السابعة، بما في ذلك HTTP، HTTPS، TCP، UDP، MQTT، إلخ.

نظرًا لأن Apache APISIX يعتمد على NGINX، يمكنك بشكل طبيعي استخدام Apache APISIX بدلاً من NGINX للتعامل مع حركة المرور الشمالية-الجنوبية. في الوقت نفسه، يمكن لـ Apache APISIX أيضًا التعامل مع حركة المرور بين الخدمات الصغيرة بشكل جيد، لذا يمكنك استخدامه لاستبدال Envoy. لدينا أيضًا بعض المستخدمين الذين يستخدمون Apache APISIX كوحدة تحكم دخول (ingress controller) لـ Kubernetes. في الوقت نفسه، بمساعدة إضافة MQTT في Apache APISIX، يمكننا استخدام Apache APISIX كبوابة إنترنت الأشياء (IoT)، أو استخدام إضافة IDP لتحويل APISIX إلى بوابة عدم الثقة (zero-trust gateway). لذا فإن APISIX تهتم أكثر بالقوة على البوابة نفسها. من خلال الإضافات، يمكن للمستخدمين تحويل APISIX إلى بوابات مختلفة مطلوبة لأعمالهم.

هذا هو الهيكل التقني لـ Apache APISIX. من هذا يمكننا أن نرى أن APISIX يتكون من جزأين، الجزء الأيسر هو مستوى البيانات، والجزء الأيمن هو مستوى التحكم.

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

ثم دعونا ننظر إلى مستوى التحكم. في مستوى التحكم، يقوم المسؤول بكتابة التكوينات إلى مجموعة etcd من خلال واجهة برمجة التطبيقات الإدارية (admin API)، وسوف يراقب مستوى بيانات APISIX etcd، بحيث تصل التكوينات إلى جميع مستويات البيانات في غضون أجزاء من الثانية. بعد معالجة العقد في مستوى البيانات للبيانات، تقوم بإرسال بعض المقاييس وبيانات السجلات إلى مكونات مثل SkyWalking، Prometheus، إلخ.

من مخطط الهيكل هذا، يمكننا أن نرى أن APISIX يعتمد فقط على etcd، ولا يحتوي على RDS مثل MySQL وPostgreSQL. لذلك، تم تصميم APISIX بشكل أفضل لتوفير التوفر العالي. في الوقت نفسه، سيكون هيكله أبسط، مما يسهل النشر والإدارة.

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

يدعم Apache APISIX أيضًا العديد من مراكز اكتشاف الخدمات الخارجية، بما في ذلك etcd وConsul.

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

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

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

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

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

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

دعونا نلقي نظرة أولاً على Kong. إنه مشروع بوابة API معروف. عمره 5 سنوات. تكمن تقنية Kong بشكل أساسي في نفس تقنية APISIX، وكلاهما يعتمدان على NGINX وLua. لكن الهيكل التقني لـ Kong ليس هو نفسه APISIX. يعتمد Kong على RDS مثل PostgreSQL وCassandra. بينما يستخدم APISIX etcd، وحل APISIX أقرب إلى Kubernetes والسحابة الأصلية.

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

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

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

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

حلول Kong وEnvoy هي نفسها: يأملون في أن يكون لدى المزيد من المطورين القدرة على تطوير الإضافات، سواء كانوا يستخدمون Go، Lua أو WASM. لذا، بالعودة إلى APISIX، نأمل في العثور على الحل السحري.

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

الأولى هي أن العديد من الإضافات التي تحتاج إلى التطوير هي في الواقع بسيطة. كيف يمكن إعادة استخدام أكثر من 40 إضافة مفتوحة المصدر الموجودة بالفعل؟

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

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

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

يمكننا جعل كل إضافة تقوم بميزة واحدة فقط، تمامًا مثل الخدمة الصغيرة، وهو نفس تصميم العمليات في Linux. لذلك، قمنا باقتراح مفهوم يسمى الإضافة الصغيرة (micro-plugin).

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

على سبيل المثال، أقوم أولاً باستدعاء إضافة حظر URI. بعد الانتهاء من الاستدعاء، سأحكم ما إذا كان URI محظورًا بالفعل. إذا كان محظورًا، فسأستمر في استدعاء إضافة Kafka.

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

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

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

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

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

على سبيل المثال، في محرك العمليات في الصناعة الطبية، يتم بناؤها بطريقة واجهة المستخدم الرسومية (GUI)، لأن مستخدميهم هم الأطباء. ثم، لعبة الليغو للأطفال هي نفسها. يمكنك استخدام عدد محدود من القطع لبناء عدد لا نهائي من الأشكال الممكنة.

بجمع أفكار واجهة المستخدم الرسومية والليغو معًا، يمكننا أن نرى أنها في الواقع Scratch، وهي الطريقة التي يتعلم بها الأطفال البرمجة، لذا ستكون العتبة منخفضة جدًا.

بناءً على المشكلتين السابقتين التي قمنا بحلهما، اقترح APISIX بشكل فريد مفهومًا جديدًا: تنسيق الإضافات (plugin orchestration). هنا عرض توضيحي لتنسيق الإضافات، يمكننا مشاهدة هذا الفيديو القصير أولاً.

في هذا الفيديو، نقوم أولاً بإنشاء إضافة حظر URI، ثم نقوم بإنشاء شرط تحكم. إذا كان حظر URI صحيحًا، فسنضيفه إلى إضافة حقن الخطأ (fault injection plugin)؛ إذا كانت نتيجة حظر URI خاطئة، فسنمررها إلى إضافة Kafka لتسجيل السجلات.

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

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

لتنفيذ تنسيق الإضافات، نحتاج إلى اتخاذ ثلاث خطوات.

في الخطوة الأولى، نحتاج إلى استخدام DAG لوصف هذه الإضافة الجديدة. يمكننا أن نرى أن الرسم البياني مع السهم على اليسار هو في الواقع DAG (رسم بياني موجه غير دوري)، وهو نفس الكود الموصوف في الفيديو السابق. ثم هذه طريقة وصف صديقة للبشر. بالنسبة للكمبيوتر، علينا تحويلها إلى لغة وصف لهيكل بيانات على اليمين. على سبيل المثال، العقدة رقم 1 متبوعة بـ 2 4 6 تعني العقدة 1، والتي تشير إلى العقدة الثانية، الرابعة والسادسة؛ قيمة العقدة رقم 3 هي nil، مما يعني أنه لا توجد عقد أخرى خلف العقدة رقم 3، والباقي مشابه. بهذه الطريقة، نحول DAG إلى وصف لهيكل بيانات.

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

بعد الخطوة الأولى، أصبح لدينا بالفعل سلسلة موصوفة بـ JSON، ولكن كيف نحول هذه السلسلة إلى كود يمكن تشغيله بواسطة APISIX؟

نحن نعلم أننا في APISIX نقوم بتشغيل كود Lua، لذا نحتاج إلى مترجم، لتحليل JSON إلى شجرة تركيب مجردة (AST)، وأخيرًا توليد كود Lua. في هذه المرحلة، استخدمنا jsonschema للقيام بهذه الخطوة. أدناه مستودع المصدر المفتوح.

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

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

إذا وصلت إلى هنا، هل لديك سؤال، أين يمكنني تجربتها؟ لا تقلق، هناك مشروع مفتوح المصدر هنا، ولدينا أيضًا عرض توضيحي عبر الإنترنت.

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

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

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

المشاريع المفتوحة المصدر حول معالجة حركة المرور تزدهر، يمكننا أن نرى BFE من Baidu وMOSN من Alibaba. كلها تركز على حركة المرور.

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

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

النقطة الثالثة هي الوقت الفعلي (real time). مع انتشار 5G وإنترنت الأشياء، وتطبيق Kubernetes في المؤسسات، تم وضع متطلبات عالية جدًا للتأثير الفوري للتكوين، عملية الطلبات، وتحليل البيانات في الوقت الفعلي. بالنسبة للبوابة، إذا لم تتمكن من العمل في الوقت الفعلي، بأداء عالي جدًا، وزمن انتقال منخفض جدًا، فلن تتمكن من البقاء في السنوات الثلاث إلى الخمس القادمة.

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

الأمر نفسه ينطبق على بوابة API. المصدر المفتوح يسمح للشركات باستخدامها بتكلفة أقل دون القلق من قفل البائع (vendor lock-in). علاوة على ذلك، فإن الفرصة التجارية للمصدر المفتوح ستجلب المزيد للمطورين المفتوحين المصدر. هذا نموذج جيد للفوز المشترك.