هل خدمة Azure SignalR جاهزة للاستخدام في الإنتاج؟
نعم، يتوفر كل من دعم ASP.NET Core SignalR وASP.NET SignalR بشكل عام.
عندما تكون هناك خوادم تطبيقات متعددة، هل يتم إرسال رسائل العميل إلى كافة الخوادم أم إلى خادم واحد منها فقط؟
هناك تعيين واحد لواحد بين العميل وخادم التطبيق. يتم إرسال الرسائل من عميل واحد دوماً إلى نفس خادم التطبيق.
يتم الحفاظ على التعيين حتى يتم قطع اتصال العميل أو خادم التطبيق.
إذا كان أحد خوادم التطبيق الخاص بي معطلاً، فكيف يمكنني العثور عليه وإخطاري؟
تراقب خدمة Azure SignalR كشوف الأخطاء من خوادم التطبيقات. إذا لم يتم تلقي رسائل كشف أخطاء الاتصال لفترة زمنية محددة، يعتبر خادم التطبيق غير متصل. سيتم قطع اتصال كافة اتصالات العميل المعينة إلى خادم التطبيق هذا.
لماذا يطرح "IUserIdProvider" المخصص استثناء عند التبديل من ASP.NET Core SignalR SDK إلى Azure SignalR Service SDK؟
تختلف المعلمة HubConnectionContext context بين ASP.NET Core SignalR SDK وAzure SignalR Service SDK عند استدعاء IUserIdProvider.
في ASP.NET Core SignalR، يعد HubConnectionContext context هو السياق من اتصال العميل الفعلي مع قيم صالحة لجميع الخصائص.
في Azure SignalR Service SDK، يعد HubConnectionContext context هو السياق من اتصال العميل المنطقي. العميل الفعلي متصل بمثيل خدمة Azure SignalR، لذلك يتم توفير عدد محدود من الخصائص فقط.
في الوقت الراهن، تتوفر فقط HubConnectionContext.GetHttpContext() وHubConnectionContext.User للوصول.
يمكنك التحقق من التعليمة البرمجية المصدر.
هل يمكنني تكوين وسائل النقل المتوفرة في خدمة Azure SignalR على جانب الخادم باستخدام ASP.NET Core SignalR؟ على سبيل المثال، هل يمكنني تعطيل نقل WebSocket؟
نعم. راجع تكوين النقل لمعرفة كيفية التكوين.
يمكنك أيضا تكوين عمليات النقل من جانب العميل كما هو موثق في تكوين ASP.NET Core SignalR.
ما معنى المقاييس مثل عدد الرسائل أو عدد الاتصالات المعروض في مدخل Azure؟ ما نوع التجميع الذي يجب أن أختاره؟
يمكنك العثور على تفاصيل حول حساب هذه المقاييس في الرسائل والاتصالات في خدمة Azure SignalR.
في جزء النظرة العامة لموارد خدمة Azure SignalR، اخترنا بالفعل نوع التجميع المناسب لك. يمكنك استخدام المقاييس المدعومة مع Azure Monitor كمرجع.
ما معنى أوضاع الخدمة "الافتراضية" و"بلا خادم" و"الكلاسيكية"؟ كيف يمكنني الاختيار؟
بالنسبة للتطبيقات الجديدة، يجب استخدام الوضع الافتراضي ووضع بلا خادم فقط. الفرق الرئيسي هو ما إذا كان لديك خوادم تطبيقات تنشئ اتصالات الخادم بالخدمة (على سبيل المثال، تستخدم AddAzureSignalR() للاتصال بالخدمة). إذا كانت الإجابة بنعم، فاستخدم الوضع الافتراضي، وإلا استخدم وضع «بلا خادم».
تم تصميم الوضع الكلاسيكي للتوافق مع الإصدارات السابقة للتطبيقات الموجودة، لذلك لا ينبغي استخدامه للتطبيقات الجديدة.
لمزيد من المعلومات حول وضع الخدمة، راجع وضع الخدمة في خدمة Azure SignalR.
هل يمكنني إرسال رسالة من العميل في وضع بلا خادم؟
يمكنك إرسال رسالة من العميل إذا قمت بتكوين نقاط النهاية المصدر في مثيل SignalR. نقاط النهاية المصدر هي مجموعة من نقاط النهاية التي يمكن أن تتلقى الرسائل وأحداث الاتصال من خدمة SignalR. إذا لم يتم تكوين نقاط نهاية المصدر، سيتم تجاهل الرسائل من العميل.
لمزيد من المعلومات.راجع نقاط النهاية الأولية.
ميزة نقاط النهاية الأولية حاليا في المعاينة العامة.
هل هناك أي اختلافات في استخدام خدمة Azure SignalR مع ASP.NET SignalR؟
عند استخدام خدمة Azure SignalR، لا يتم دعم بعض واجهات برمجة التطبيقات وميزات ASP.NET SignalR:
- القدرة على تمرير حالة عشوائية بين العملاء والمركز (غالبا ما يسمى
HubState) غير مدعومة. PersistentConnectionالفئة غير مدعومة.- نقل إطار إلى الأبد غير مدعوم.
- لم تعد خدمة Azure SignalR تعيد عرض الرسائل المرسلة إلى العميل عندما يكون العميل غير متصل.
- عند استخدام خدمة Azure SignalR، يتم توجيه حركة مرور اتصال عميل واحد دائمًا (وتسمى أيضاً sticky) إلى مثيل خادم تطبيق واحد طوال مدة الاتصال.
يركز دعم ASP.NET SignalR على التوافق، لذلك لا يتم دعم جميع الميزات الجديدة من ASP.NET Core SignalR. على سبيل المثال، تتوفر خدمتا MessagePack وStreaming فقط لتطبيقات ASP.NET Core SignalR.
يمكنك تكوين خدمة Azure SignalR لأوضاع الخدمة المختلفة: Classic وDefault وServerless. Serverless الوضع غير مدعوم ASP.NET. كما أن واجهة برمجة تطبيقات REST على مستوى البيانات غير معتمدة.
أين توجد بياناتي؟
لا تقوم خدمة Azure SignalR بتخزين أي بيانات العملاء. إذا كنت تستخدم خدمة Azure SignalR مع خدمات Azure الأخرى، مثل Azure Storage للتشخيص، فشاهد نظرة عامة على خصوصية Azure (مستند تقني) للحصول على إرشادات حول كيفية الاحتفاظ بإقامة البيانات في مناطق Azure.
كيف أعمل الاختيار بين خدمة Azure SignalR وخدمة Azure Web PubSub؟
تساعد كل من خدمة Azure SignalR Service وخدمة Azure Web PubSub العملاء على إنشاء تطبيقات ويب في الوقت الحقيقي بسهولة مع إمكانية تغيير حجمها وتوفيرها على نطاق واسع، كما أنهما تتيحان للعملاء إمكانية التركيز على منطق أعمالهم بدلاً من إدارة البنية التحتية لنظام المراسلة. بشكل عام، يمكنك اختيار خدمة Azure SignalR إذا كنت تستخدم مكتبة SignalR بالفعل لإنشاء تطبيقات في الوقت الفعلي. أو إذا كنت تبحث، بدلاً من ذلك، عن حل عام لإنشاء تطبيق في الوقت الحقيقي استناداً إلى بروتوكول WebSocket ونمط الإرسال من الناشر إلى المشترك، يمكنك اختيار خدمة PubSub Azure Web. خدمة Azure Web PubSub ليست بديلا لخدمة Azure SignalR والعكس صحيح؛ وهي تستهدف سيناريوهات مختلفة. ستساعدك الإرشادات التالية على تحديد الخدمة التي يجب استخدامها للسيناريو الخاص بك.
تُعد خدمة Azure SignalR Service مناسبة أكثر عندما يلي:
- تستخدم بالفعل مجموعة تقنيات ASP.NET أو مكتبة ASP.NET Core SignalR، أو تستخدم برنامج .NET بشكل رئيسي، أو تحتاج إلى الاندماج مع النظام البنائي .NET (مثل Blazor).
- وجود عميل SignalR متاح للمنصة الخاصة بك.
- تحتاج إلى بروتوكول راسخ يدعم مجموعة متنوعة من:
- أنماط الاتصال (RPC والتدفق)
- عمليات النقل (WebSocket والأحداث المرسلة من الخادم والاستقصاء الطويل)
- تحتاج إلى عميل يدير مدة بقاء الاتصال نيابة عنك.
تعد خدمة Azure Web PubSub مناسبة أكثر للحالات التالية:
- عندما تحتاج إلى إنشاء تطبيقات في الوقت الحقيقي استناداً إلى تقنية WebSocket أو نمط الإرسال من الناشر إلى المشترك عبر بروتوكول WebSocket.
- عندما تريد إنشاء بروتوكول فرعي خاص بك أو استخدام البروتوكولات المتقدمة الحالية عبر بروتوكول WebSocket (على سبيل المثال، MQTT أو AMQP عبر بروتوكول WebSocket).
- عندما تبحث عن خادم خفيف، على سبيل المثال، لإرسال رسائل إلى العميل دون المرور بالخلفية المكوَّنة.