كيف يدعم Azure Web PubSub مكتبة Socket.IO؟

توفر هذه المقالة منظورا هندسيا حول كيفية ترحيل تطبيقات Socket.IO المستضافة ذاتيا إلى Azure باستخدام Web PubSub Socket.IO مع الحد الأدنى من تغييرات التعليمات البرمجية. يمكنك بعد ذلك الاستفادة من بنية التطبيق المبسطة ونشرها، مع تحقيق 100000 اتصال متزامن. لا تحتاج إلى فهم كل شيء في هذه المقالة لاستخدام Web PubSub Socket.IO بشكل فعال.

بنية تطبيق Socket.IO مستضاف ذاتيا

يوضح الرسم التخطيطي التالي بنية نموذجية لتطبيق Socket.IO مستضاف ذاتيا.

Diagram of a typical architecture of a self-hosted Socket.IO app, including clients, servers, a load balancer, and an adapter.

لضمان أن التطبيق قابل للتطوير وموثوق به، غالبا ما يكون لدى المستخدمين Socket.IO بنية تتضمن خوادم Socket.IO متعددة. يتم توزيع اتصالات العميل بين خوادم Socket.IO لموازنة التحميل على النظام.

يقدم إعداد خوادم Socket.IO متعددة تحديا عندما يحتاج المطورون إلى إرسال نفس الرسالة إلى العملاء المتصلين بخادم مختلف. غالبا ما يشير المطورون إلى حالة الاستخدام هذه على أنها "بث الرسائل".

التوصية الرسمية من مكتبة Socket.IO هي تقديم مكون من جانب الخادم يسمى محول لتنسيق خوادم Socket.IO. يحدد المحول الخوادم التي يتصل بها العملاء ويوجه هذه الخوادم لإرسال الرسائل.

إضافة مكون محول يقدم تعقيد لكل من التطوير والنشر. على سبيل المثال، إذا كانت البنية تستخدم محول Redis، يحتاج المطورون إلى:

  • تنفيذ جلسات العمل الملصقة.
  • نشر مثيلات Redis وصيانتها.

إن الجهد الهندسي والوقت في الحصول على قناة اتصال في الوقت الحقيقي يصرف المطورين عن العمل على الميزات التي تجعل التطبيق أو النظام فريدا وقيما للمستخدمين.

ما هو Web PubSub Socket.IO يهدف إلى حله للمطورين

على الرغم من أن المطورين غالبا ما يبلغون عن أن إعداد تطبيق موثوق وقابل للتطوير تم إنشاؤه باستخدام مكتبة Socket.IO أمر صعب، يمكن للمطورين الاستفادة من واجهات برمجة التطبيقات البديهية ومجموعة واسعة من العملاء التي تدعمها المكتبة. ويب PubSub for Socket.IO يبني على القيمة التي تجلبها المكتبة، مع تخفيف المطورين من التعقيد في إدارة الاتصالات المستمرة بشكل موثوق وعلى نطاق واسع.

في الممارسة العملية، يمكن للمطورين الاستمرار في استخدام واجهات برمجة التطبيقات لمكتبة Socket.IO دون الحاجة إلى توفير موارد الخادم للحفاظ على WebSocket أو الاتصالات المستندة إلى الاستقصاء الطويل، والتي يمكن أن تكون كثيفة الموارد. أيضا، لا يحتاج المطورون إلى إدارة مكون محول ونشره. يحتاج خادم التطبيق إلى إرسال عملية واحدة فقط، ويبث Web PubSub Socket.IO الرسائل إلى العملاء ذوي الصلة.

كيفية عمله

يعتمد Web PubSub for Socket.IO على بروتوكولات Socket.IO من خلال تنفيذ المحول Engine.IO. يوضح الرسم التخطيطي التالي البنية النموذجية عند استخدام Web PubSub Socket.IO مع خادم Socket.IO.

Screenshot of a typical architecture of a fully managed Socket.IO app.

مثل تطبيق Socket.IO المستضاف ذاتيا، لا تزال بحاجة إلى استضافة منطق تطبيق Socket.IO على الخادم الخاص بك. ومع ذلك، مع Web PubSub لخدمة Socket.IO:

  • لم يعد الخادم الخاص بك يدير اتصالات العميل مباشرة.
  • ينشئ عملاؤك اتصالات مستمرة مع الخدمة (اتصالات العميل).
  • تنشئ الخوادم أيضا اتصالات مستمرة بالخدمة (اتصالات الخادم).

عندما يستخدم send to clientمنطق الخادم الخاص بك و broadcastو add client to rooms، يتم إرسال هذه العمليات إلى الخدمة من خلال اتصال خادم تم تأسيسه. تتم ترجمة الرسائل الواردة من الخادم إلى عمليات Socket.IO يمكن للعملاء Socket.IO فهمها. ونتيجة لذلك، يمكن أن يعمل أي تنفيذ Socket.IO موجود دون تعديلات رئيسية. التعديل الوحيد الذي تحتاج إلى إجراءه هو تغيير نقطة النهاية التي يتصل بها عملاؤك. لمزيد من المعلومات، راجع ترحيل تطبيق Socket.IO مستضاف ذاتيا لإدارته بالكامل على Azure.

عندما يتصل عميل بالخدمة، تكون الخدمة:

  • إعادة توجيه اتصال Engine.IO (connect) إلى الخادم.
  • يعالج ترقية النقل لاتصالات العميل.
  • إعادة توجيه جميع الرسائل Socket.IO إلى الخادم.