هذه المقالة ترجمة لمقال كيفن غولدبيرغ "مقدمة لخوادم Python WSGI: الجزء الأول" blog.appdynamics.com/engineering/an-introduction-to-python-wsgi-servers-part-1 مع إضافات صغيرة من المترجم
تاريخ موجز لخوادم WSGI Python
ظهرت خوادم
WSGI لأن خوادم الويب في ذلك الوقت لم تكن قادرة على التفاعل مع التطبيقات المكتوبة في Python.
تم تطوير WSGI (
تنطق "whiz-gee" بعبارة "g" )
الصلبة بواسطة Philip J. Ebi (إلى جانب Ian Biking وآخرين) في أوائل العقد الأول من القرن الحادي والعشرين. وحدة أباتشي ، والمعروفة باسم
mod_python ، التي طورها Grigory Trubetskoy في أواخر التسعينيات ، في ذلك الوقت عالجت معظم تطبيقات Python. ومع ذلك ،
لم يكن
mod_python مواصفات رسمية. تم إنشاؤه ببساطة بحيث يمكن للمطورين تشغيل كود Python على الخادم. لسوء الحظ ، كان هذا النهج غير آمن وبدأ المطورون في البحث عن حل جديد.
WSGI (واجهة بوابة خادم الويب) هي سليل
CGI (واجهة البوابة المشتركة). عندما بدأت الويب في التطور ، نمت
CGI بسبب دعم عدد كبير من اللغات وعدم وجود حلول أخرى. ومع ذلك ، كان هذا الحل بطيئا ومحدودا. تم تطوير
WSGI كواجهة لطلبات التوجيه من خوادم الويب (Apache ، Nginx ، إلخ) إلى تطبيقات الويب.
الخادم وتطبيق الويب
في أبسط الحالات ، تتكون
WSGI من كيانين رئيسيين:
- خادم الويب ( Nginx ، Apache ، إلخ.) ؛
- تطبيق ويب مكتوب بلغة Python.
مبدأ العمل:
يقوم خادم الويب بتنفيذ التعليمات البرمجية ويرسل المعلومات ووظيفة رد الاتصال المرتبطة بطلب http إلى تطبيق الويب. ثم تتم معالجة الطلب على جانب التطبيق وإرسال استجابة إلى خادم الويب.
بشكل دوري ، بين خادم الويب وتطبيق الويب ، توجد طبقة وسيطة واحدة أو أكثر. تسمح هذه الطبقات ، على سبيل المثال ، بالتوازن بين تطبيقات الويب المتعددة والمعالجة المسبقة (المعالجة المسبقة) للمحتوى المقدم.
فيما يلي أمثلة على الأطر التي تدعم WSGI:
لماذا WSGI؟
قد تسأل ،
"حسنًا ، ولكن لماذا WSGI؟" . هناك عدة أسباب لذلك:
- تم تصميم خوادم WSGI للتعامل مع العديد من الطلبات في وقت واحد. والأطر ليست مصممة للتعامل مع آلاف الطلبات ولا تعطي قرارًا حول أفضل طريقة لتوجيهها (الطلبات) من خادم الويب.
- تعمل WSGI على تسريع تطوير تطبيقات الويب المكتوبة بلغة Python. إذا كنت تستخدم إطار عمل (Django أو أي شيء آخر) في تطوير تطبيق الويب الخاص بك ، فلا داعي للقلق بشأن كيفية استخدام البنية التحتية الخاصة بك لمعيار WSGI .
- يمنحك WSGI المرونة لتعديل مكونات مكدس ويب دون تغيير التطبيق الذي يعمل مع WSGI .
تتوفر خوادم
WSGI في أشكال مختلفة. يهدف البعض إلى حل Fullstack ، في حين أن البعض الآخر مناسب تمامًا لأطر عمل محددة. على سبيل المثال ، يعمل
Gunicorn مع
Django خارج الصندوق. فيما يلي نظرة فاحصة على خوادم WSGI الستة الموجودة في السوق اليوم:
Bjoern و
uWSGI و
mod_wsgi و
Meinheld و
CherryPy و
Gunicorn .
بجورن
Bjoern هو خادم WSGI غير متزامن مكتوب بلغة C. مكتوب من الألف إلى الياء ليكون صغيرًا وسريعًا ، وقد تم تطويره باستخدام
http_parser من Ryan Dahl (منشئ Node.js)
وحلقة حدث
Libev من Mark Lehmann.
مع حجم تنزيل يبلغ 18 كيلوبايت فقط ، يتكون من أقل من 800 سطر من التعليمات البرمجية. تستهلك أقل من 1 ميغابايت من ذاكرة الوصول العشوائي ولا تستخدم
coroutines أو مؤشرات الترابط.
Bjoern متوافق تمامًا مع
WSGI ويعتبر أحد خوادم
WSGI عالية الأداء.
يدعم
Bjoern الاتصالات المستمرة ويمكنه الارتباط بمقابس يونيكس أو عناوين TCP. يعتبر
Bjoern أسرع من Gunicorn وأقل
انتفاخًا من
uWSGI و
Meinheld . أحد عيوب هذا الخادم هو عدم وجود وثائق عادية مع أمثلة واضحة.
UWSGI
تم تطوير
uWSGI بواسطة
Unbit (إيطاليا) بهدف أن تصبح حلًا متكاملًا قادرًا على إنشاء خدمات الاستضافة. تم تسميته وفقًا لمعيار
WSGI وتم إنشاؤه
كمكوِّن إضافي لأحد مشروعات الشركة.
يتيح لك مشروع
UWSGI ، وهو مشروع واسع ومتطور باستمرار ، القيام بأكثر من مجرد تطبيقات استضافة الويب. يجد الكثيرون أن
UWSGI أداة قوية ، بينما يجدها آخرون منتفخة إلى حد ما. بدءًا من الإصدار 2.0 ، يدعم uWSGI أيضًا إطلاق تطبيقات الويب باللغات Lua و Perl و Ruby وغيرها.
mod_wsgi
mod_wsgi ، وحدة خادم Apache HTTP تم تطويرها بواسطة Graham Dumpleton (سابقًا أحد مطوري
mod_python ) ، توفر واجهة
WSGI لتطبيقات الويب. متوافق مع إصدارات لغة Python2 و Python3. تم إنشاؤها كبديل للحلول الأخرى لدمج تطبيقات الويب مثل
CGI و
FastCGI و
mod_python . يمكن تثبيته كوحدة Apache أو عبر
mod_wsgi express . تبسط الطريقة الثانية التثبيت لمطوري Python غير المعتادين على Apache. مزايا أخرى:
• لا تحتاج إلى امتيازات الجذر مع التثبيت الكامل.
• يتم إنشاء بيئة محلية ، مما يقلل من خطر التأثير السلبي على الإعدادات الحالية.
قد يبدو تطوير
mod_wsgi كمشروع بطيئًا نظرًا لأنه تم تطوير الوحدة بواسطة مطور واحد. عيب آخر هو أن الوثائق ضعيفة التنظيم حاليًا وقد تكون قديمة.
حاليًا ، يتم التركيز على تبسيط تنفيذ Apache باستخدام
mod_wsgi في البيئات باستخدام
Docker .
مينهولد
Meinheld ، الذي
أنشأه Yutaka Matsubara ، هو خادم متوافق مع
WSGI يستفيد من قوة
picoev و
greenlet لأداء I / O غير متزامن. يمكن استخدامه مع خادم HTTP مستقل أو من خلال
Gunicorn .
تعتمد
Meinheld على مكون تابع لجهة خارجية يسمى greenlet.
يقع مستودع شفرة المصدر على
جيثب . يدعم
Meinheld مآخذ الويب ويتضمن العديد من
بقع القرود على الوحدات الأخرى لتحسين الأداء.
شيريبي
CherryPy - المعروف باسم إطار عمل Python أضيق الحدود لكتابة تطبيقات الويب ، يأتي
CherryPy أيضًا مع خادم ويب WSGI المجمع لمؤشر الترابط ودعم بروتوكول HTTP / 1.1. يصف فريق تطوير
CherryPy خادم الويب الخاص به على أنه خادم HTTP جاهز للإنتاج وعالي السرعة
ومترابط . لديه:
• إعداد سريع وسهل.
• قابلية التوسع.
• حل صغير وسهل الاستخدام لتطبيقات Python الخاصة بك ؛
• دعم SSL.
تميز
CherryPy نفسها عن خوادم
WSGI الأكثر شهرة بسبب سهولة الاستخدام وسهولة المطورين. يمكنك كتابة تطبيق ويب صغير في بضع دقائق عن طريق تشغيله في عدة عمليات وإنشاء ملف واحد فقط يسمى server.py. من خلال الجمع بين
CherryPy و Nginx
كخادم وكيل ، يمكنك الحصول على طريقة موثوقة لخدمة تطبيقات الويب الخاصة بك. تم إنشاء
CherryPy بواسطة Remy
Delon . لقد أراد إنشاء هيكل يكون قريبًا قدر الإمكان من
المبادئ الرئيسية للتنمية في Python .
Gunicorn
Gunicorn هو
خادم WSGI مصمم للاستخدام على أنظمة UNIX. الاسم نسخة مختصرة ومجمعة من الكلمات "يونيكورن الخضراء". يوجد يونيكورن أخضر في موقع المشروع نفسه. تم نقل
Gunicorn من مشروع Unicorn من Ruby. إنه سريع نسبيًا ، ومكثف الموارد ، وسهل التشغيل ، ويعمل مع مجموعة واسعة من أطر الويب.
يوصي فريق التطوير باستخدام
Gunicorn بالاشتراك مع Nginx ، حيث يتم استخدام Nginx
كخادم وكيل.
الخلاصة
في هذا المقال ، تم
تحليل خوادم WSGI الستة الأكثر شيوعًا في الوقت الحالي:
Bjoern و
uWSGI و
mod_wsgi و
Meinheld و
CherryPy و
Gunicorn . يعتمد الخادم الذي تستخدمه لك على شروط ومتطلبات تطبيقك. سيحلل الجزء التالي أداء خوادم WSGI الستة هذه.