سيتم إطلاق xRPC، تعرف على المزيد من التفاصيل حول نظام APISIX البيئي

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

في هذه المقالة، سنقدم لكم أمثلة عن إطار عمل xRPC القادم لـ Apache APISIX والإضافات متعددة اللغات من منظورين: الوكيل متعدد البروتوكولات والدعم متعدد اللغات.

الوكيل متعدد البروتوكولات

في Apache APISIX، كل طلب يتوافق مع كائن Route. هناك حاليًا سيناريوهان رئيسيان للوكيل في Apache APISIX.

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

الثاني هو وكيل بروتوكول ديناميكي يعتمد على TCP وUDP مع موازنة الحمل، والذي يوفر أبسط قدرات قبول حركة المرور وقدرات تسجيل الروابط. يمكن لهذا النموذج الوكيل أن يعمل كوسيط لأي طلبات تعتمد على بروتوكولات TCP/UDP مثل MySQL، Redis، Mongo أو DNS. ومع ذلك، نظرًا لأنه وكيل يعتمد على TCP/UDP بدون بروتوكولات طبقة التطبيق العليا، فإنه يمكن الحصول فقط على بعض المعلومات الأساسية حول الرباعية، مما يجعله أقل قوة من حيث قابلية التوسع.

لماذا xRPC

بسبب قيود Stream Route في وكيل البروتوكولات، ورغبتنا في دعم المزيد من بروتوكولات طبقة التطبيق على APISIX لخدمة المزيد من المستخدمين وسيناريوهات التطبيق، ولد إطار عمل xRPC.

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

ما هو xRPC

xRPC تعني حرفيًا أن X هو تمثيل مجرد لمورد بروتوكول. وRPC هو ما نعتبره جميع الموارد التي تمر عبر البوابة كعملية إرسال، أي أنه إطار عمل لتوسيع البروتوكولات. لذلك من حيث التوجه، xRPC هو إطار عمل أساسي وليس تنفيذًا لبروتوكول محدد.

كما يمكنك أن ترى من الهندسة أعلاه، xRPC هو إطار عمل يعتمد على توسيعات APISIX Core. على هذا الإطار، يمكن للمستخدمين تنفيذ بروتوكولات طبقة تطبيق مختلفة، مثل Redis، MySQL، Mongo وPostgres. على رأس البروتوكولات المختلفة، يمكنك تجريد بعض العوامل المشتركة وتنفيذ القدرات ذات الصلة بالإضافات بحيث يمكن للبروتوكولات المختلفة مشاركة هذه القدرات.

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

أمثلة على سيناريوهات التطبيق

مع وجود إطار عمل بروتوكول xRPC، ما هي السيناريوهات التي يمكن أن يعالجها؟ إليك بعض الأمثلة.

• المثال 1: لا يدعم Redis TLS في الإصدارات السابقة. إذا كان لدينا إصدارات متعددة من Redis في نظامنا، ولا يمكننا ترقية Redis في الإنتاج لبعض الأسباب، ولكننا بحاجة إلى إضافة قدرة TLS. في هذه الحالة، يمكننا استخدام بروتوكول Redis القائم على xPRC لحل الوضع أعلاه.
• المثال 2: عندما نريد تحديد تردد معين لبعض عناوين IP أو المتصلين ونريد تصور تردد كل مصدر اتصال، وهو ما لا يدعمه Redis. يتم حل هذا بشكل مثالي باستخدام بروتوكول Redis، الذي يتم توسيعه بواسطة xRPC.
• المثال 3: إذا كنت ترغب في استخدام MySQL لتمكين وظيفة الاستعلام البطيء مؤقتًا، فما عليك سوى الوصول إلى MySQL Protocol وتكوين السياسة ذات الصلة في APISIX، مما يوفر عليك الخطوة المملة لتسجيل الدخول إلى الآلة مثيلًا تلو الآخر.

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

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

مراحل التنفيذ المخطط لها

التصميم الحالي لإطار عمل Apache APISIX xRPC مقسم في البداية إلى 5 مراحل.

• المرحلة 1: قراءة البيانات وفك تشفير البروتوكول.
• المرحلة 2: مرحلة الوصول. توفير وظيفة الوصول للإضافات، والتي يمكن أن تحقق سيناريوهات الطلب للأمان، التحكم في التدفق، والوصول.
• المرحلة 3: توجيه البيانات وموازنة الحمل. توفير دعم الوصول لسياسات وخوارزميات موازنة الحمل المخصصة.
• المرحلة 4: إرسال البيانات وترميز البروتوكول.
• المرحلة 5: مرحلة التسجيل. توفير الوصول للإضافات لتحقيق سيناريوهات الطلب للتسجيل والتسجيل.

البيئة متعددة اللغات

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

على سبيل المثال، قام مؤخرًا بتنفيذ دعم لـ WebAssembly. للتفاصيل والميزات، يرجى الرجوع إلى المقالة "Apache APISIX يعانق بيئة WASM". بالطبع، دعم WASM في Apache APISIX لا يزال تجريبيًا، وسنواصل تحسين الدعم لـ WASM في المستقبل. إذا كنت مهتمًا بهذا المشروع، يرجى المساهمة في مشروع wasm-nginx-module.

في الوقت نفسه، يدعم Apache APISIX بالفعل العديد من لغات التطوير من خلال "xPluginRunner Multilanguage Plugin Runtime" قبل تنفيذ دعم WASM. أي عند تطوير إضافات APISIX، يمكن للمستخدمين كتابة وتوسيع إضافات APISIX ليس فقط باستخدام كود Lua، الذي يدعمه APISIX بشكل أصلي، ولكن أيضًا باستخدام لغاتهم المألوفة، مثل Go، Java وPython.

xPluginRunner

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

يعمل xPluginRunner كجسر للتواصل مع Apache APISIX، ويقوم بشكل رئيسي بتحليل بروتوكولات البيانات الخاصة وتغليف وفك تغليف رسائل RPC.

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

• apisix-go-plugin-runner
• apisix-java-plugin-runner
• apache-apisix-python-runner

أخيرًا، سنعرض لكم كيفية تطوير إضافات APISIX بناءً على Java Plugin Runner بمثال بسيط باستخدام Java.

مثال Java Plugin Runner

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

نقطة إضافية يجب ملاحظتها هي أن المعلمات request وresponse التي تظهر في الكود أعلاه لها منطق ثابت في Runner (جميع Runners تنطبق):

1. إذا كنت تريد أن يستمر الطلب في التوجيه وتريد فقط القيام ببعض إعدادات السياسة (مثل إعادة كتابة معلمات الطلب، الرؤوس، إلخ)، يمكنك ببساطة التعامل مع كائن request.
2. إذا كنت تريد إنهاء الطلب، يمكنك القيام بذلك باستخدام كائن response (مثل تعيين نص الاستجابة، رؤوس الاستجابة، رموز الحالة، إلخ).

سيقوم APISIX بإنهاء الطلب الحالي بمجرد أن يشعر بأن كائن response في Runner قد تم التعامل معه.

بمجرد اكتمال تطوير الإضافة، حان وقت ممارسة التطبيق في APISIX.

أولاً، قم بتجميع Runner والإضافات في المشروع إلى حزم jar وقم بتكوين المسار المطلق لحزم jar في ملف تكوين APISIX الرئيسي بالطريقة التالية.

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

الخلاصة

تقدم هذه المقالة الإصدار القادم لإطار عمل xRPC لـ Apache APISIX والتفاصيل ذات الصلة، بالإضافة إلى عرض تفصيلي لدعم Apache APISIX في التطوير متعدد اللغات.

تظهر المقالة أيضًا تفاصيل دعم Apache APISIX للتطوير متعدد اللغات. تظهر الجهود الموجهة نحو البيئة لـ Apache APISIX من منظورين: الوكيل متعدد البروتوكولات والدعم متعدد اللغات.

لا تتردد في بدء مناقشة في GitHub Discussions أو التواصل عبر قائمة البريد.