ينظر المهندسون أحيانًا إلى تحجيم WebSocket على أنه "هل يمكن لوقت التشغيل X استيعاب N من الاتصالات؟"
هذا ضيق جدًا.
السؤال الأصعب عادةً هو:
"هل يمكن لهذا النظام إدارة حالة الاتصال طويلة الأمد، والتوزيع الانتقائي، والعملاء البطيئين دون أن ينهار؟"
التكاليف الحقيقية
يجب أن يتعامل نظام WebSocket مع:
- حالة الاتصال المستمرة
- معالجة المصادقة وإعادة الاتصال
- التوزيع للعديد من المشتركين
- الضغط العكسي من المستهلكين البطيئين
- التنسيق عبر العقد إذا كنت تقوم بتحجيم أفقيًا
عدد الاتصالات مهم. شكل التوزيع أكثر أهمية.
الاتصالات التي تقترب من عشرة آلاف معظمها غير نشط تمثل مشكلة مختلفة عن عشرة آلاف مشترك يتلقون بثًا متكررًا.
لماذا تعاني Node في كثير من الأحيان
يمكن لـ Node أن تدير أنظمة WebSocket بشكل ممتاز.
تبدأ الضغوط عندما يقوم التطبيق بالعمل الكثير لكل رسالة على نفس حلقة الأحداث المسؤولة عن إبقاء المقابس في حالة جيدة. بمجرد تراكم حلقات البث، التسلسل، والمحاسبة لكل عميل، تصبح السعة الزمنية مرئية بسرعة.
هذا ليس إدانة لـ Node. إنه تذكير بأن نموذج وقت التشغيل وشكل الحمل يجب أن يتطابقا.
لماذا يتم ذكر Elixir/Phoenix بشكل متكرر
تعتبر Elixir ونظام BEAM شائعين في هذا المجال لأنهما مصممان حول أعداد كبيرة من العمليات الخفيفة وتمرر الرسائل. يمكن أن يجعل ذلك أنظمة الاتصال أسهل في التفكير من الناحية التشغيلية.
الميزة الحقيقية ليست "يمكن لـ Elixir إدارة مليون مقبس" كشعار. بل إن الإشراف، والعزلة، والتزامن جزء من النموذج بدلاً من أن تكون شيئًا ملحقًا به.
قاعدة التصميم التي تهم
إذا كنت بحاجة إلى تسليم في الوقت الحقيقي على نطاق واسع، ركز على:
- الحفاظ على حالة الاتصال لكل عميل صغيرة
- تقسيم الغرف أو المواضيع بشكل نظيف
- تطبيق الضغط العكسي
- قياس تكلفة التوزيع
- اختيار وقت تشغيل يتناسب مع الحمل
أحيانًا تكون Node جيدة بما يكفي.
أحيانًا تكون Go أو Elixir أكثر ملاءمة.
السؤال الهندسي الجاد ليس أي لغة تفوز بمجادلات الإنترنت. إنه أي وقت تشغيل يجعل أساليب الفشل قابلة للإدارة بالنسبة لنمط حركة المرور لديك.
مزيد من القراءة