وضع الخدمة في خدمة Azure SignalR
وضع الخدمة هو مفهوم مهم في خدمة Azure SignalR. تدعم SignalR Service حاليا ثلاثة أوضاع للخدمة: افتراضي وبلا خادم وكلاسيك. سيتصرف مورد SignalR Service بشكل مختلف في كل وضع. في هذه المقالة، ستتعلم كيفية اختيار وضع الخدمة المناسب استنادا إلى السيناريو الخاص بك.
تعيين وضع الخدمة
سيطلب منك تحديد وضع خدمة عند إنشاء مورد SignalR جديد في مدخل Microsoft Azure.
يمكنك أيضا تغيير وضع الخدمة لاحقا في قائمة الإعدادات.
استخدم az signalr create و az signalr update لتعيين أو تغيير وضع الخدمة باستخدام Azure SignalR CLI.
الوضع الافتراضي
كما يوحي الاسم، الوضع الافتراضي هو وضع الخدمة الافتراضي لخدمة SignalR. في الوضع الافتراضي، يعمل التطبيق الخاص بك كتطبيق نموذجي ASP.NET Core SignalR أو ASP.NET SignalR (مهمل). لديك تطبيق خادم ويب يستضيف مركز، يسمى خادم المركز، والعملاء لديهم اتصال مزدوج كامل مع خادم المركز. الفرق بين ASP.NET Core SignalR وخدمة Azure SignalR هو بدلا من توصيل العميل وخادم المركز مباشرة، يتصل العميل والخادم بخدمة SignalR ويستخدمان الخدمة كوكيل. يوضح الرسم التخطيطي التالي بنية التطبيق النموذجية في الوضع الافتراضي.
عادة ما يكون الوضع الافتراضي هو الخيار الصحيح عندما يكون لديك تطبيق SignalR تريد استخدامه مع SignalR Service.
توجيه الاتصال في الوضع الافتراضي
في الوضع الافتراضي، هناك اتصالات WebSocket بين خادم المركز وخدمة SignalR تسمى اتصالات الخادم. يتم استخدام هذه الاتصالات لنقل الرسائل بين الخادم والعميل. عند توصيل عميل جديد، ستقوم SignalR Service بتوجيه العميل إلى خادم مركز واحد (افترض أن لديك أكثر من خادم واحد) من خلال اتصالات الخادم الموجودة. سيلتزم اتصال العميل بنفس خادم المركز خلال مدة بقائه. يشار إلى هذه الخاصية باسم ثبات الاتصال. عندما يرسل العميل رسائل، فإنها تنتقل دائما إلى نفس خادم المركز. باستخدام سلوك الثبات، يمكنك الحفاظ بأمان على بعض الحالات للاتصالات الفردية على خادم المركز. على سبيل المثال، إذا كنت تريد دفق شيء ما بين الخادم والعميل، فلن تحتاج إلى مراعاة الحالة التي تنتقل فيها حزم البيانات إلى خوادم مختلفة.
هام
في الوضع الافتراضي، لا يمكن للعميل الاتصال دون اتصال خادم لوحة الوصل بالخدمة أولا. إذا تم قطع اتصال جميع خوادم المركز بسبب انقطاع الشبكة أو إعادة تشغيل الخادم، فستتلقى اتصالات العميل خطأ يخبرك بأنه لا يوجد خادم متصل. تقع على عاتقك مسؤولية التأكد من وجود خادم مركز واحد على الأقل متصل بخدمة SignalR. على سبيل المثال، يمكنك تصميم التطبيق الخاص بك مع خوادم مركز متعددة، ثم التأكد من أنها لن تعمل كلها دون اتصال في نفس الوقت.
يعني نموذج التوجيه الافتراضي أيضا أنه عند عدم اتصال خادم المركز، سيتم إسقاط الاتصالات التي تم توجيهها إلى هذا الخادم. يجب أن تتوقع انخفاض الاتصالات عندما يكون خادم المركز غير متصل بالإنترنت للصيانة، ومعالجة إعادة الاتصال لتقليل التأثيرات على التطبيق الخاص بك.
إشعار
في الوضع الافتراضي، يمكنك أيضا استخدام واجهة برمجة تطبيقات REST وSDK للإدارة وربط الوظائف لإرسال الرسائل مباشرة إلى عميل إذا كنت لا تريد الانتقال عبر خادم المركز. في الوضع الافتراضي، لا تزال اتصالات العميل تتم معالجتها بواسطة خوادم المركز ولن تعمل نقاط النهاية الأولية في هذا الوضع.
وضع بلا خادم
على عكس الوضع الافتراضي، لا يتطلب الوضع بلا خادم تشغيل خادم لوحة الوصل، ولهذا السبب يسمى هذا الوضع "بلا خادم". خدمة SignalR مسؤولة عن الحفاظ على اتصالات العميل. لا يوجد ضمان لثبات الاتصال وقد تكون طلبات HTTP أقل كفاءة من اتصالات WebSockets.
يعمل الوضع بلا خادم مع Azure Functions لتوفير إمكانية المراسلة في الوقت الحقيقي. يعمل العملاء مع روابط SignalR Service ل Azure Functions، تسمى ربط الوظائف، لإرسال الرسائل كربط إخراج.
نظرا لعدم وجود اتصال بالخادم، إذا حاولت استخدام خادم SDK لإنشاء اتصال خادم، فستتلقى خطأ. سترفض خدمة SignalR محاولات اتصال الخادم في الوضع بلا خادم.
لا يحتوي الوضع بلا خادم على ثبات الاتصال، ولكن لا يزال بإمكانك الحصول على رسائل دفع تطبيق من جانب الخادم للعملاء. هناك طريقتان لدفع الرسائل إلى العملاء في وضع بلا خادم:
- استخدام واجهات برمجة تطبيقات REST لحدث إرسال لمرة واحدة، أو
- استخدم اتصال WebSocket بحيث يمكنك إرسال رسائل متعددة بشكل أكثر كفاءة. يختلف اتصال WebSocket هذا عن اتصال الخادم.
إشعار
يتم دعم كل من واجهة برمجة تطبيقات REST وWebSockets في SDK لإدارة خدمة SignalR. إذا كنت تستخدم لغة أخرى غير .NET، يمكنك أيضا استدعاء واجهات برمجة تطبيقات REST يدويا باتباع هذه المواصفات.
من الممكن أيضا لتطبيق الخادم الخاص بك تلقي الرسائل وأحداث الاتصال من العملاء. ستقوم SignalR Service بتسليم الرسائل وأحداث الاتصال إلى نقاط النهاية المكونة مسبقا (تسمى نقاط النهاية المصدر) باستخدام خطافات الويب. يمكن تكوين نقاط النهاية الأولية فقط في وضع بلا خادم. لمزيد من المعلومات، راجع نقاط النهاية الأولية.
يوضح الرسم التخطيطي التالي كيفية عمل الوضع بلا خادم.
الوضع الكلاسيكي
إشعار
الوضع الكلاسيكي هو أساسا للتوافق مع الإصدارات السابقة للتطبيقات التي تم إنشاؤها قبل تقديم الوضعين الافتراضي وبلا خادم. لا تستخدم الوضع الكلاسيكي إلا كملاذ أخير. استخدم Default أو Serverless للتطبيقات الجديدة، استنادا إلى السيناريو الخاص بك. يجب أن تفكر في إعادة تصميم التطبيقات الموجودة للقضاء على الحاجة إلى الوضع الكلاسيكي.
الكلاسيكي هو وضع مختلط للأوضاع الافتراضية وبلا خادم. في الوضع الكلاسيكي، يتم تحديد نوع الاتصال من خلال ما إذا كان هناك خادم مركز متصل عند إنشاء اتصال العميل. إذا كان هناك خادم مركز، فسيتم توجيه اتصال العميل إلى خادم لوحة الوصل. إذا لم يكن خادم المركز متوفرا، فسيتم إجراء اتصال العميل في وضع محدود بلا خادم حيث لا يمكن تسليم رسائل العميل إلى الخادم إلى خادم المركز. لا تدعم الاتصالات بلا خادم في الوضع الكلاسيكي بعض الميزات مثل نقاط النهاية الأولية.
إذا كانت جميع خوادم المركز غير متصلة لأي سبب من الأسباب، فسيتم إجراء الاتصالات في وضع بلا خادم. تقع على عاتقك مسؤولية التأكد من توفر خادم مركز واحد على الأقل دائما.
اختيار وضع الخدمة المناسب
الآن يجب أن تفهم الاختلافات بين أوضاع الخدمة ومعرفة كيفية الاختيار بينها. كما تمت مناقشته سابقا، لا ينصح بالوضع الكلاسيكي للتطبيقات الجديدة أو الموجودة. فيما يلي بعض التلميحات التي يمكن أن تساعدك على اتخاذ الخيار الصحيح لوضع الخدمة ومساعدتك على إيقاف الوضع الكلاسيكي للتطبيقات الموجودة.
اختر الوضع الافتراضي إذا كنت على دراية بكيفية عمل مكتبة SignalR وتريد الانتقال من SignalR المستضاف ذاتيا لاستخدام خدمة Azure SignalR. يعمل الوضع الافتراضي تماما بنفس الطريقة التي يعمل بها SignalR المستضاف ذاتيا، ويمكنك استخدام نفس نموذج البرمجة في مكتبة SignalR. تعمل SignalR Service كوكيل بين العملاء وخوادم المركز.
اختر وضع بلا خادم إذا كنت تقوم بإنشاء تطبيق جديد ولا تريد الاحتفاظ بخادم المركز واتصالات الخادم. يعمل الوضع بلا خادم مع Azure Functions بحيث لا تحتاج إلى الحفاظ على أي خادم على الإطلاق. لا يزال بإمكانك الحصول على اتصالات مزدوجة كاملة مع واجهة برمجة تطبيقات REST أو SDK للإدارة أو ربط الوظائف + نقطة نهاية المصدر، ولكن نموذج البرمجة سيكون مختلفا عن مكتبة SignalR.
اختر الوضع الافتراضي إذا كان لديك كل من خوادم المركز لخدمة اتصالات العميل وتطبيق الواجهة الخلفية لدفع الرسائل مباشرة إلى العملاء. الفرق الرئيسي بين الوضع الافتراضي ووضع بلا خادم هو ما إذا كان لديك خوادم المركز وكيفية توجيه اتصالات العميل. يمكن استخدام واجهة برمجة تطبيقات REST/إدارة SDK/ربط الوظائف في كلا الوضعين.
إذا كان لديك سيناريو مختلط بالفعل، يجب أن تفكر في فصل حالات الاستخدام إلى مثيلات خدمة SignalR متعددة مع تعيين وضع الخدمة وفقا للاستخدام. مثال على سيناريو مختلط يتطلب الوضع الكلاسيكي هو المكان الذي يكون لديك فيه مركزان مختلفان على نفس مورد SignalR. يتم استخدام مركز واحد كمركز SignalR تقليدي ويتم استخدام المركز الآخر مع Azure Functions. يجب تقسيم هذا المثال إلى موردين، مع مثيل واحد في الوضع الافتراضي والآخر في الوضع بلا خادم.
الخطوات التالية
راجع المقالات التالية لمعرفة المزيد حول كيفية استخدام الوضعين الافتراضي وبلا خادم.