يصف هذا السيناريو كيفية تصميم حل يعالج التغييرات على البيانات الأساسية داخل طريقة عرض الويب، دون الحاجة إلى تحديث الصفحة، باستخدام الخدمات في الوقت الحقيقي. تتضمن الأمثلة التي تستخدم هذا السيناريو تعقب المنتجات والسلع في الوقت الحقيقي وحلول وسائل التواصل الاجتماعي.
بناء الأنظمة
قم بتنزيل ملف Visio لهذه البنية.
المكونات
- ناقل خدمة Azure هي خدمة مراسلة سحابية موثوقة للغاية بين التطبيقات والخدمات، حتى عندما يكون واحد أو أكثر غير متصل.
- تسهل خدمة Azure SignalR إضافة اتصالات في الوقت الحقيقي إلى تطبيق الويب الخاص بك.
- Azure Functions هو نظام أساسي للحوسبة بلا خادم يستند إلى الحدث ويمكنه أيضا حل مشكلات التنسيق المعقدة.
البدائل
توجد بدائل لمعالجة هذا السيناريو، بما في ذلك Pusher. إنها الفئة الرائدة في واجهات برمجة التطبيقات القوية لمطوري التطبيقات الذين ينشئون ميزات اتصال قابلة للتطوير في الوقت الحقيقي.
هناك أيضا PubNub. يسهل PubNub عليك إضافة قدرات في الوقت الحقيقي إلى تطبيقاتك، دون القلق بشأن البنية الأساسية. إنشاء تطبيقات تسمح للمستخدمين بالانخراط في الوقت الحقيقي عبر الأجهزة المحمولة والمستعرض وسطح المكتب والخادم.
Ably هو بديل آخر. يوفر مراسلة نشر/اشتراك بلا خادم (pub/sub)، والتي تتوسع بشكل موثوق مع احتياجاتك. يتم تسليم المراسلة على الحافة باستخدام WebSockets. يوفر النظام الأساسي Ably بنية أساسية متاحة للغاية وقابلة للتطوير بشكل مرن وموزعة عالميا في الوقت الحقيقي، بناء على استدعاء واجهة برمجة التطبيقات.
على الرغم من أن Pusher و PubNub و Ably هي الأنظمة الأساسية الأكثر اعتمادا للمراسلة في الوقت الحقيقي، لهذا السيناريو، ستقوم بكل شيء في Azure. نوصي SignalR كنظام أساسي للانتقال إلى، لأنه يسمح بالاتصال ثنائي الاتجاه بين الخادم والعميل. كما أنها أداة مفتوحة المصدر، مع 7.9 ألف نجمة GitHub و2.2 ألف GitHub forks.
لمزيد من المعلومات، راجع مستودع SignalR مفتوح المصدر على GitHub.
تفاصيل السيناريو
في هذا السيناريو، ستنظر في كيفية إعداد خدمة مراسلة في الوقت الحقيقي لمشاركة الموقع المباشر معاملة خدمة توصيل الطعام. يمكن أن يكون هذا المثال مفيدا أيضا لأولئك الذين يحاولون إنشاء نظام أساسي لمشاركة الموقع في الوقت الحقيقي لتطبيقات الويب أو الأجهزة المحمولة الخاصة بهم.
ستستخدم خدمة SignalR التي تم تكوينها في وضع بلا خادم للتكامل مع تطبيق Azure Functions الذي يتم تشغيله بواسطة ناقل خدمة، كل ذلك باستخدام .NET Core.
حالات الاستخدام المحتملة
حالات الاستخدام الأخرى هذه لها أنماط تصميم مماثلة:
- مشاركة الموقع في الوقت الحقيقي مع أجهزة العميل
- دفع الإعلامات إلى المستخدمين
- تحديث المخططات الزمنية
- إنشاء غرف محادثة
الاعتبارات
تطبق هذه الاعتبارات ركائز إطار العمل جيد التصميم في Azure، وهي مجموعة من المبادئ التوجيهية التي يمكنك استخدامها لتحسين جودة حمل العمل. لمزيد من المعلومات، راجع إطار العمل جيد التصميم في Microsoft Azure.
فيما يلي بعض الأشياء التي يجب وضعها في الاعتبار أثناء تطوير هذا السيناريو، بما في ذلك كيفية تكوين المعلمات في سلسلة الاتصال ناقل خدمة Azure في ServiceBusTrigger:
- المراكز: يمكن مقارنة المراكز بخدمة دفق الفيديو. يمكنك الاشتراك في مركز لإرسال الرسائل وتلقيها منه.
- الأهداف: الأهداف مثل القنوات الراديوية. وهي تشمل كل من يستمع إلى القناة الهدف، ويتم إعلامه عندما تكون هناك رسالة جديدة عليها.
إذا كان بإمكانك تذكر الميزتين السابقتين للنظام الأساسي SignalR، فسيكون من السهل البدء والتشغيل بسرعة.
التوفر وقابلية التوسع والأمان
يمكنك تحقيق قابلية وصول عالية مع هذا الحل باتباع ما هو موضح في القسمين التاليين.
الاقتران الإقليمي
يتم إقران كل منطقة من مناطق Azure بمنطقة أخرى داخل نفس المنطقة الجغرافية. بشكل عام، اختر مناطق من نفس الزوج الإقليمي (على سبيل المثال، شرق الولايات المتحدة 2 ووسط الولايات المتحدة). تشمل مزايا القيام بذلك ما يلي:
- إذا كان هناك انقطاع واسع، يتم إعطاء الأولوية لاستعادة منطقة واحدة على الأقل من كل زوج.
- يتم طرح تحديثات نظام Azure المخططة للمناطق المقترنة بالتتابع لتقليل وقت التوقف المحتمل.
- في معظم الحالات، تتواجد الأزواج الإقليمية داخل نفس المنطقة الجغرافية لتلبية متطلبات موقع البيانات.
- ومع ذلك، تأكد من أن كلتا المنطقتين تدعمان جميع خدمات Azure المطلوبة لتطبيقك. راجع الخدمات حسب المنطقة. لمزيد من المعلومات حول الأزواج الإقليمية، راجع استمرارية الأعمال والإصلاح بعد كارثة (BCDR): المناطق المقترنة في Azure.
Azure Front Door
تنزيل Visio file لهذه البنية.
Azure Front Door هو نقطة إدخال قابلة للتطوير وآمنة للتسليم السريع لتطبيقات الويب العالمية. عند استخدام توجيه الأولوية، فإنه يفشل تلقائيا إذا أصبحت المنطقة الأساسية غير متوفرة. يمكن أن توفر بنية متعددة المناطق قابلية وصول أعلى من النشر في منطقة واحدة. إذا كان الانقطاع الإقليمي يؤثر على المنطقة الأساسية، فيمكن استخدام Front Door لتجاوز الفشل في المنطقة الثانوية.
يمكن أن تساعد هذه البنية أيضاً في حالة فشل النظام الفرعي الفردي للتطبيق. أوقف هجمات طبقة الشبكة والتطبيق على الحافة باستخدام Web Application Firewall وDDoS Protection. تقوية الخدمة باستخدام مجموعات القواعد التي تديرها Microsoft، وتأليف القواعد الخاصة بك للحماية المخصصة لتطبيقك.
الباب الأمامي هو نقطة فشل محتملة في النظام. إذا فشلت الخدمة، فلن يتمكن العملاء من الوصول إلى التطبيق الخاص بك أثناء وقت التعطل. راجع اتفاقية مستوى خدمة Front Door (SLA) وحدد ما إذا كان استخدام Front Door وحده يلبي متطلبات عملك لتحقيق قابلية وصول عالية. إذا لم يكن الأمر كذلك، ففكر في إضافة حل آخر لإدارة نسبة استخدام الشبكة كإجراء احتياطي. في حال فشل خدمة Front Door، قم بتغيير سجلات الاسم المتعارف عليه (CNAME) في DNS للإشارة إلى خدمة إدارة نسبة استخدام الشبكة الأخرى. يجب تنفيذ هذه الخطوة يدويا، ولن يكون التطبيق الخاص بك متوفرا حتى يتم نشر تغييرات DNS.
تحسين التكلفة
يركز تحسين التكلفة على البحث عن طرق للحد من النفقات غير الضرورية وتحسين الكفاءة التشغيلية. لمزيد من المعلومات، يرجى مراجعةنظرة عامة على ركيزة تحسين التكلفة.
لنفترض أن شركتك لديها 1000 طلب يوميا وتحتاج إلى مشاركة بيانات الموقع معها جميعا بشكل متزامن. سيكون استخدام Azure المقدر لنشر هذا السيناريو قريبا من 192 دولارا أمريكيا شهريا، استنادا إلى الأسعار في تاريخ النشر.
| نوع الخدمة | التكلفة الشهرية المقدرة |
|---|---|
| دالات Azure | 119.40 دولار أمريكي |
| Azure SignalR Service | 48.97 دولار أمريكي |
| ناقل خدمة Azure | 23.71 دولار أمريكي |
| الإجمالي | 192.08 دولار أمريكي |
نشر هذا السيناريو
تطوير Azure Functions
يتطلب التطبيق بلا خادم في الوقت الحقيقي الذي تم إنشاؤه باستخدام Azure Functions وخدمة Azure SignalR عادة وظيفتين من Azure:
negotiateدالة يستدعيها العميل للحصول على رمز مميز صالح للوصول إلى SignalR Service وعنوان URL لنقطة نهاية الخدمة.- دالة واحدة أو أكثر ترسل رسائل أو تدير عضوية المجموعة.
SignalRFunctionApp
SignalRFunctionApp هو تطبيق وظائف ينشئ مثيل Azure Functions، مع مشغل ناقل خدمة مع SignalR.
Negotiate.cs
يتم تشغيل الدالة بواسطة طلب HTTP. يتم استخدامه من قبل تطبيقات العميل للحصول على رمز مميز من خدمة SignalR، والتي يمكن للعملاء استخدامها للاشتراك في مركز. يجب تسمية negotiateهذه الدالة . لمزيد من المعلومات، راجع تطوير وتكوين Azure Functions باستخدام Azure SignalR Service،
Message.cs
يتم تشغيل هذه الدالة بواسطة مشغل ناقل خدمة. لديها ربط بيانات مع خدمة SignalR. حيث تسحب الرسالة من قائمة الانتظار وتمررها إلى مركز SignalR.
الإرشادات
قبل البدء:
- تأكد من أن لديك قائمة انتظار ناقل خدمة تم توفيرها على Azure.
- تأكد من أن لديك خدمة SignalR تم توفيرها في وضع بلا خادم على Azure.
- أدخل سلاسل الاتصال (ناقل الخدمة و SignalR) في ملف local.settings.json .
- أدخل عنوان URL لتطبيق العميل (عميل SignalR) في CORS (مشاركة الموارد عبر المنشأ). للحصول على أحدث بناء جملة، راجع تطوير وتكوين Azure Functions باستخدام Azure SignalR Service.
- أدخل اسم قائمة انتظار ناقل الخدمة في مشغل ناقل الخدمة في ملف Message.cs .
الآن، دعونا نقوم بتكوين تطبيق العميل لاختباره. أولا، احصل على أمثلة المصادر من صفحة GitHub لبنية الحل .
عميل SignalR
هذا تطبيق ويب .NET Core بسيط للاشتراك في المركز الذي تم إنشاؤه بواسطة SignalRFunctionApp. يعرض الرسائل التي يتم تلقيها في قائمة انتظار ناقل الخدمة في الوقت الفعلي. على الرغم من أنه يمكنك استخدام SignalRFunctionApp للعمل مع عميل محمول، دعنا نلتزم بعميل الويب لهذا السيناريو في هذا المستودع.
الإرشادات
تأكد من تشغيل SignalRFunctionApp.
انسخ عنوان URL الذي تم إنشاؤه بواسطة دالة التفاوض. يبدو شيئا مثل هذا:
http://localhost:7071/api/.الصق عنوان URL في ملف chat.js ، داخل
signalR.HubConnectionBuilder().withUrl("YOUR_URL_HERE").build();.شغّل التطبيق.
يتم توصيل الحالة عندما يشترك عميل الويب بنجاح في مركز SignalR.
SendToQueue.js
يدفع هذا البرنامج النصي node.js رسالة إلى ناقل خدمة Microsoft Azure، بحيث يمكنك اختبار التوزيع الذي أكملته للتو.
الإرشادات
قم بتثبيت الوحدة النمطية لعقدة ناقل خدمة Microsoft Azure (@ azure / service-bus).
أدخل سلاسل الاتصال واسم قائمة الانتظار في البرنامج النصي.
قم بتشغيل البرنامج النصي.
الخطوات التالية
يمكنك أخذ هذا السيناريو في بيئة الإنتاج الخاصة بك. ومع ذلك، تأكد من تعيين خدمات Azure على التحجيم. على سبيل المثال، يجب تعيين ناقل خدمة Azure إلى خطة قياسية أو متميزة.
يمكنك نشر التعليمات البرمجية إلى Azure Functions مباشرة من Visual Studio. لمعرفة كيفية نشر التعليمات البرمجية الخاصة بك إلى Azure Functions من Visual Studio، اتبع كيفية إنشاء دليل البرامج .
تعرف على كيفية العمل مع روابط ناقل خدمة Azure في Azure Functions. تدعم Azure Functions روابط المشغل والإخراج لقوائم انتظار وموضوعات ناقل الخدمة.
تعرف على كيفية مصادقة رسائل في الوقت الحقيقي وإرسالها إلى العملاء المتصلين بخدمة Azure SignalR، باستخدام روابط SignalR Service في Azure Functions. تدعم Azure Functions روابط الإدخال والإخراج لخدمة SignalR.