الأسئلة الهامة التي يجب على مطوري Workerman معرفتها

1. القيود المفروضة على بيئة Windows

تحتاج الإصدارات الخاصة بـ Workerman على نظام ويندوز إلى قائمة اتصال تصل إلى 200+ لكل عملية فردية. بينما لا يمكن استخدام معلمة count لضبط عمليات فوق غيرها. بالإضافة إلى ذلك، لا يمكن استخدام أوامر مثل status و stop و reload و restart. كما أنه لا يمكن تشغيل الخدمات بشكل مستمر دون وجود النافذة الفعلية cmd. وأيضًا لا يمكن تهيئة عدة استماعات في نفس الملف. بينما لا توجد هذه القيود في أنظمة Linux، ولذا يفضل استخدام نظام Linux في البيئة الإنتاجية وأنظمة ويندوز في البيئة التطويرية.

2. Workerman لا يعتمد على Apache أو Nginx

في حال كانت البيئة متاحة، يمكن تشغيل Workerman بسهولة نظرًا لأنه يعتبر وحده نوعًا من الأنظمة القائمة على سيرفرات مثل Apache و Nginx.

3. تشغيل Workerman عبر سطر الأوامر

يتم تشغيل Workerman بشكل مشابه لتشغيل Apache عبر سطر الأوامر (وعادة لا يمكن استخدام Workerman في مساحة الاستضافة). الشكل النموذجي للتشغيل كما يلي:

4. الاتصالات الدائمة تتطلب Heartbeat

يجب إضافة heartbeats إلى الاتصالات الدائمة. وهذا يعني أن الاتصالات الدائمة بحاجة إلى heartbeats لتجنب تسريح الاتصال بسبب عدم التواصل لفترة طويلة. يمكن الرجوع إلى شرح heartbeats بـ Workerman وشرح heartbeats بـ GatewayWorker للمزيد من المعلومات.

5. يجب أن تكون بروتوكولات العميل والخادم متناسبة حتى يتسنى التواصل

هذه مشكلة شائعة لدى المطورين. على سبيل المثال، إذا استخدم العميل بروتوكول websocket، يجب أن يكون الخادم أيضًا بروتوكول websocket (الخادم: new Worker('websocket://0.0.0.0...')) لضمان التواصل. يجب تجنب محاولة الوصول إلى منفذ بروتوكول websocket عبر شريط عناوين المواقع، وتجنب استخدام بروتوكول webscoket للوصول إلى منفذ بروتوكول TCP المجرد. وبالمقارنة، فإن هذا المبدأ يشبه التواصل مع الأشخاص حيث يجب أن يتحدث كل طرف (العميل والخادم) لغة واحدة لكي يتم التواصل، وإلا سيكون التواصل مستحيلاً.

6. أسباب فشل الاتصالات المحتملة

مشكلة شائعة في بداية استخدام Workerman هي فشل اتصال العميل بالخادم. وتعتمد الأسباب عادةً على:

1. منع جدار الحماية للاتصالات (بما في ذلك مجموعات الأمان للخوادم السحابية)، يصل إلى 50% من احتمالية حدوث هذه المشكلة.
2. عدم تطابق البروتوكولات المستخدمة بين العميل والخادم، بحدود 30%.
3. الخطأ في كتابة عنوان IP أو رقم المنفذ، بحدود 15%.
4. عدم تشغيل الخادم.

7. تجنب استخدام أوامر exit وdie وsleep

استخدام أوامر exit وdie أثناء تنفيذ الأعمال قد يؤدي إلى إغلاق العملية مما يسفر عن ظهور رسالة خطأ "WORKER EXIT UNEXPECTED". وبالطبع، سيتم إعادة تشغيل العملية فور إغلاقها لمواصلة تقديم الخدمة. وإذا كان هناك حاجة للعودة إلى الشاشة السابقة، يمكن استدعاء return بدلًا من الأوامر الخمس نقاط. أما الأمر sleep، فسيؤدي إلى توقف العملية في النوم مما يودي إلى توقف جميع طلبات العملاء وتوقف تشغيل الأطر، مما يجعل عملية التعامل معها مستحيلة.

8. تجنب استخدام الدالة pcntl_fork

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

9. تجنب وجود حلقات بيانات لا نهاية لها في كود الأعمال

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

10. تحتاج إعادة تشغيل الكود لرؤية التغييرات

Workerman هو إطار عمل مستمر في الذاكرة، وبالتالي يجب إعادة تشغيل Workerman لرؤية تأثيرات الكود الجديد.

11. توصى باستخدام GatewayWorker لتطبيقات الاتصالات الدائمة

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

12. دعم الاستجابة الأعلى

إذا كان عدد الاتصالات المتصلة في الوقت نفسه يتجاوز 1000، فإنه من الضروري قيام بتحسين نواة لينكس، وتثبيت ملحق الحدث.