ما الفرق بين OpenResty و NGINX؟
API7.ai
September 9, 2022
مزايا OpenResty واضحة، قبل التعلم بالتفصيل، دعونا نستعرض بإيجاز عملية تطوير OpenResty، مما سيساعدك على فهم المحتوى التالي بشكل أفضل.
عملية تطوير OpenResty
لم يتم بناء OpenResty من الصفر مثل لغات التطوير الأخرى، ولكنه يعتمد على مكونات مفتوحة المصدر ناضجة - NGINX و LuaJIT. ولد OpenResty في عام 2007، ولكن نسخته الأولى لم تختار Lua، بل Perl، وهو ما يرتبط كثيرًا بتفضيلات المؤلف التقنية.
لكن أداء Perl كان بعيدًا عن تلبية المتطلبات، لذلك في النسخة الثانية، تم استبدال Perl بـ Lua. ومع ذلك، في المشروع الرسمي لـ OpenResty، لا يزال Perl يلعب دورًا مهمًا. يتم بناء مشروعات نظام OpenResty باستخدام Perl، مثل إطار الاختبار، Linter، CLI، إلخ. سنقدمها بالتفصيل لاحقًا.
نظرًا لأن أداء OpenResty العالي ومزاياه الديناميكية مناسبة جدًا لاحتياجات أعمال CDN، أصبح OpenResty بسرعة المعيار التقني لـ CDN. علاوة على ذلك، من خلال مكتبات lua-resty-* الغنية، بدأ OpenResty في التخلص تدريجيًا من ظل NGINX وتشكيل نظامه البيئي، والذي يستخدم على نطاق واسع في بوابات API، WAF الناعم، وغيرها من المجالات.
أقول دائمًا أن OpenResty هي تقنية مستخدمة على نطاق واسع، ولكنها ليست تقنية ساخنة، وهذا يبدو متناقضًا. ماذا يعني ذلك؟
إنها مستخدمة على نطاق واسع لأن OpenResty هو الآن خادم الويب الخامس الأكثر استخدامًا في العالم.
إنها ليست شائعة لأن نسبة استخدام OpenResty لبناء أنظمة الأعمال ليست عالية. معظم المستخدمين يستخدمون OpenResty لمعالجة حركة المرور الواردة، ولا يتعمقون في الأعمال. لذا، بطبيعة الحال، استخدام OpenResty هو مجرد تذوق سطحي، وهو كافٍ لتلبية الاحتياجات الحالية. هذا بالطبع يرتبط أيضًا بعدم وجود أطر عمل ويب ناضجة ونظام بيئي مثل Java و Python في OpenResty.
بعد قول كل هذا، سأركز في ما يلي على تقديم بعض النقاط التي تستحق الإشادة والتعلم في مشروع OpenResty مفتوح المصدر.
نقاط بارزة في OpenResty
وثائق مفصلة وحالات اختبار
نعم، الوثائق والاختبارات هي مؤشرات حاسمة لمدى موثوقية مشروع مفتوح المصدر، حتى قبل جودة الكود والأداء.
وثائق OpenResty مفصلة جدًا، وقد كتب المؤلف كل نقطة تحتاج إلى انتباه في الوثائق. معظم الوقت، نحتاج فقط إلى النظر بعناية في الوثائق لحل المشكلة التي نواجهها دون الحاجة إلى البحث في Google أو تتبع الكود المصدري. لتسهيل الأمر، يأتي OpenResty أيضًا مع أداة سطر أوامر، restydoc، المصممة لمساعدتك على عرض الوثائق من خلال shell وتجنب الانقطاعات في عملية الترميز.
ومع ذلك، هناك فقط مقتطفات كود واحدة أو اثنتين متاحة في الوثائق، ولا توجد أمثلة كاملة ومعقدة. أين يمكن العثور على مثل هذه الأمثلة؟
بالنسبة لـ OpenResty، فإنه بشكل طبيعي هو دليل /t، الذي يحتوي على جميع حالات الاختبار. كل حالة اختبار تتضمن تكوين NGINX الكامل وكود Lua، بالإضافة إلى بيانات الإدخال والإخراج المتوقعة. ومع ذلك، فإن إطار الاختبار في OpenResty مختلف تمامًا عن أطر الاختبار الأخرى التي تعتمد على التأكيدات، وهو ما سأقدمه لاحقًا في فصل خاص.
متزامن غير معيق
الـ Coroutine هي ميزة جديدة أضافتها العديد من لغات البرمجة النصية في السنوات الأخيرة لتحسين الأداء. لكنها لم تُنفذ بشكل مثالي، بعضها عبارة عن سكر نحوي، وبعضها يتطلب إعلانات صريحة للكلمات المفتاحية.
OpenResty يدعم الـ Coroutine منذ اليوم الأول وينفذ نموذج برمجة متزامن غير معيق. هذا مهم لأن المبرمجين أيضًا بشر، ويجب أن يكون الكود أكثر توافقًا مع عادات التفكير البشرية. الاستدعاءات الصريحة والكلمات المفتاحية غير المتزامنة تقطع التفكير وتجعل التصحيح صعبًا.
إذن ما هو المتزامن غير المعيق؟ دعونا نتحدث أولاً عن المتزامن. هذا بسيط جدًا: التنفيذ بالتسلسل وفقًا للكود. على سبيل المثال، الكود الزائف التالي:
local res, err = query-mysql(sql) local value, err = query-redis(key)
في نفس الطلب، إذا كان علينا الانتظار حتى يعود نتيجة استعلام MySQL قبل الاستمرار في استعلام Redis، فهذا متزامن؛ إذا لم نكن بحاجة إلى الانتظار حتى يعود MySQL ويمكننا الاستمرار في استعلام Redis، فهذا غير متزامن. بالنسبة لـ OpenResty، معظم العمليات هي عمليات متزامنة. فقط واجهات برمجة التطبيقات المتعلقة بالمؤقتات الخلفية، مثل ngx.timer هي عمليات غير متزامنة.
أما بالنسبة لغير المعيق، وهو مفهوم يسهل الخلط بينه وبين غير المتزامن، عندما نقول معيق هنا، فإننا نعني تعيق خيط نظام التشغيل. دعونا نستمر في النظر إلى المثال أعلاه، بافتراض أن استعلام MySQL يستغرق 1s. إذا كان خلال هذه 1s، موارد نظام التشغيل (CPU) خاملة وتنتظر بغباء العودة، فهذا معيق؛ إذا استغل CPU الفرصة لمعالجة طلبات اتصالات أخرى، فهذا غير معيق. غير المعيق هو أيضًا المفتاح لتحقيق التزامن العالي مثل C10K و C100K.
مفهوم المتزامن غير المعيق مهم جدًا. ومع ذلك، في رأيي، لا ينبغي فهم هذا المفهوم عن طريق القياس لأن القياس غير المناسب قد يربكك أكثر.
في OpenResty، يمكن للكود الزائف أعلاه تحقيق المتزامن غير المعيق مباشرة دون الحاجة إلى كلمات مفتاحية صريحة. وهذا يعكس مرة أخرى أن تسهيل استخدام المطورين هو أحد مفاهيم OpenResty.
الديناميكية
إحدى المزايا الضخمة لـ OpenResty، والتي لم يتم استغلالها بالكامل، هي ديناميكيتها.
خوادم الويب التقليدية، مثل NGINX، تتطلب منا تعديل ملف التكوين على القرص وإعادة تحميله لتصبح التغييرات سارية المفعول لأنها لا توفر واجهات برمجة التطبيقات للتحكم في سلوك التشغيل. لذلك، في الخدمات الصغيرة التي تتطلب تغييرات متكررة، حاول NGINX عدة مرات، ولكن لم يتحسن شيء. وظهور Envoy المفاجئ، مع واجهة برمجة التطبيقات الديناميكية للتحكم xDS، يشكل تهديدًا كبيرًا لهجمات تخفيض الأبعاد لـ NGINX.
على عكس NGINX و Envoy، يتم التحكم في OpenResty بواسطة لغة البرمجة النصية Lua، والديناميكية هي ميزة طبيعية لـ Lua. على سبيل المثال، من خلال واجهة برمجة التطبيقات Lua المقدمة في وحدة lua-nginx-module في OpenResty، يمكننا التحكم ديناميكيًا في المسارات، upstreams، شهادات SSL، الطلبات، الردود، إلخ. بل يمكننا تعديل منطق معالجة الأعمال دون إعادة تشغيل OpenResty، وليس فقط الواجهات المقدمة من OpenResty.
هنا تشبيه رائع لمساعدتك على فهم ما تم قوله عن الديناميكية أعلاه. فقط فكر في خادم الويب كسيارة تسير بسرعة على الطريق السريع، NGINX يحتاج إلى التوقف لتغيير الإطارات وتغيير لون الطلاء؛ Envoy يمكنه تغيير الإطارات والألوان أثناء التشغيل؛ و OpenResty، بالإضافة إلى القدرات السابقة، يمكنه أيضًا التحول إلى سيارة دفع رباعي دون الحاجة إلى التوقف.
بعد إتقان هذه القدرة السحرية، توسعت دائرة اختصاص وخيال OpenResty إلى مجالات أخرى، مثل Serverless والحوسبة الطرفية.
ما الذي يجب تعلمه؟
بعد الحديث عن العديد من الميزات الرئيسية لـ OpenResty، ما الذي يجب أن نتعلمه؟ أفضل التركيز على الخط الرئيسي بدلاً من الإمساك بالتفاصيل الصغيرة حتى نتمكن من بناء نظام معرفي ذو سياق واضح.
يجب أن تعرف أنه بغض النظر عن مدى شمولية الدورة، فإنه من المستحيل تغطية جميع المشكلات ولا يمكن أن تساعدك مباشرة في حل كل خطأ واستثناء على الإنترنت.
بالعودة إلى دراسة OpenResty، في رأيي، إذا كنت تريد تعلم OpenResty بشكل جيد، يجب أن تفهم النقاط الثمانية الرئيسية التالية:
- نموذج البرمجة المتزامن غير المعيق
- دور مراحل الطلب/الاستجابة المختلفة
- الفروق بين LuaJIT و Lua
- واجهات برمجة التطبيقات في OpenResty والمكتبات المحيطة
- الـ Coroutine و cosocket
- إطار اختبار الوحدة وأدوات اختبار الأداء
- مخطط اللهب وسلسلة الأدوات المحيطة
- تحسين الأداء
هذه النقاط ضرورية في دراستنا، وسأناقشها بشكل منفصل في كل فصل. ومع ذلك، في عملية التعلم، أتمنى أن تتمكن من الاستنتاج من حالة واحدة وقراءة بعض الفصول بعمق وفقًا لاهتماماتك وخلفيتك.
إذا كنت مبتدئًا في OpenResty، يمكنك متابعة تقدم الدورة، تثبيت OpenResty في بيئتك، وتشغيل وتعديل نموذج الكود. تذكر، تركيزك يجب أن يكون على بناء الصورة الكبيرة لـ OpenResty، وليس التمسك بنقطة معرفية واحدة. بالطبع، إذا كان لديك أي أسئلة، فلا تتردد في الاتصال بنا في الدردشة الحية.
إذا كنت تستخدم OpenResty في مشروعك، فهذا رائع! ومع ذلك، أعتقد أنه عندما تقرأ فصول LuaJIT وتحسين الأداء، سيكون لديك المزيد من التجاوب والتطبيقات العملية وسترى تحسن الأداء قبل وبعد التحسين في مشروعك.
بالإضافة إلى ذلك، إذا كنت ترغب في المساهمة بالكود في OpenResty والمكتبات المحيطة، فإن أكبر عائق ليس فهم مبادئ OpenResty أو كيفية كتابة وحدات NGINX C، ولكن حالات الاختبار ومواصفات الكود. لقد رأيت الكثير من المساهمين في OpenResty (بما في ذلك أنا) يقومون بتعديل حالات الاختبار وأنماط الكود بشكل متكرر على PR، وهناك الكثير من القواعد غير المعلنة. لذا، فإن قسم مواصفات الكود واختبار الوحدة في الدورة مخصص لك.
وإذا كنت مهندس ضمان الجودة، حتى إذا كنت لا تستخدم OpenResty، فإن إطار اختبار OpenResty ومجموعة أدوات تحليل الأداء ستعطيك الكثير من الإلهام. بعد كل شيء، فإن استثمار OpenResty وتراكمه في الاختبارات عميق جدًا.