مشاركة عبر

IoT Hub والموثوقية

  • مقالة

Azure IoT Hub هي خدمة مُدارة مستضافة في السحابة تعمل كمركز رسائل مركزي للاتصال بين تطبيق IoT والأجهزة المتصلة به. يمكنك توصيل ملايين الأجهزة وحلولها الخلفية بشكل موثوق فيه وآمن. يمكن توصيل أي جهاز تقريبًا بمركز IoT.

يدعم IoT Hub المراقبة لمساعدتك في تعقب إنشاء الجهاز واتصالاته وحالات فشله.

يدعم IoT Hub أيضاً أنماط المراسلة التالية:

  • المعيار عن بعد من جهاز إلى سحابة
  • تحميل الملفات من الأجهزة
  • طرق الرد على الطلب للتحكم في أجهزتك من السحابة

للحصول على مزيدٍ من المعلومات حول IoT Hub، راجع مفاهيم IoT وAzure IoT Hub.

لفهم كيفية دعم IoT Hub لحمل عمل موثوق، يمكنك الرجوع إلى الموضوعات التالية:

تختص الأقسام التالية بـ Azure IoT Hub والموثوقية:

  • اعتبارات التصميم
  • قائمة مراجعة التكوين
  • خيارات التكوين الموصى بها

اعتبارات التصميم

للحصول على مزيدٍ من المعلومات عن اتفاقية مستوى الخدمة لـ Azure IoT Hub، راجع اتفاقية مستوى الخدمة لـ Azure Firewall.

قائمة الاختيار

هل قمت بتكوين Azure IoT Hub مع وضع مراعاة الموثوقية في الاعتبار؟

  • قم بتكوين إعدادات IoT Hub ثانٍ في منطقة أخرى ولديك منطق توجيه تسجيل الدخول على الجهاز.
  • استخدم بروتوكول AMQP أو MQTT عند إرسال الأحداث بشكل متكرر.
  • استخدم الشهادات التي تم التحقق من صحتها عن طريق المرجع المصدق الجذر في بيئة التشغيل فقط إذا كنت تستخدم شهادات X.509 للاتصال بالجهاز.
  • للحصول على أقصى معدل النقل، استخدم الحد الأقصى لعدد الأقسام (32) عند إنشاء IoT Hub، إذا كنت تخطط لاستخدام نقطة النهاية المضمنة.
  • بالنسبة للتحجيم، زِد المستوى وحدات IoT Hub المخصصة بدلاً من إضافة أكثر من IoT Hub لكل منطقة.
  • في سيناريوهات معدل النقل العالية، استخدم الأحداث المُنفَذة على دفعات.
  • إذا كنت تحتاج إلى أقل زمن انتقال ممكن، فلا تستخدم التوجيه واقرأ الأحداث من نقطة النهاية المضمنة.
  • كجزء من إستراتيجية قابلية الوصول على مستوى واسع للحل والإصلاح بعد كارثة، يُرجى مراعاة استخدام خيار استرداد الإصلاح بعد كارثة عبر المناطق في IoT Hub.
  • عند قراءة بيانات تتبع الاستخدام للجهاز من نقطة النهاية المضمنة المتوافقة مع مركز الأحداث، راجع توصية مستهلكي مركز الأحداث.
  • عند استخدام SDK لإرسال الأحداث إلى IoT Hubs، تأكد من الاطلاع على الاستثناءات التي تطرحها سياسة إعادة المحاولة (EventHubsException أو OperationCancelledException) بشكل صحيح.
  • لتجنب انقطاع بيانات تتبع الاستخدام بسبب التقييد والحصة النسبية المستخدمة بالكامل، يُرجى مراعاة إضافة حل مخصص للتحجيم التلقائي.

توصيات التكوين

انتبه إلى التوصيات التالية لتحسين الموثوقية عند تكوين Azure IoT Hub:

التوصية الوصف
وفِّر IoT Hub ثانياً في منطقة أخرى واتبع منطق التوجيه على الجهاز. يمكن تعزيز هذه التكوينات باستخدام خدمة Concierge.
استخدم بروتوكول AMQP أو MQTT عند إرسال الأحداث بشكل متكرر. يتميزAMQP وMQTT بتكلفة شبكة اتصال أعلى عند بدء جلسة العمل، لكن HTTPS يتطلب نفقات TLS إضافية لكل طلب. يتميز AMQP و MQTT بأداء أعلى للناشرين المتكررين.
استخدم الشهادات التي تم التحقق من صحتها عن طريق المرجع المصدق الجذر في بيئة التشغيل فقط إذا كنت تستخدم شهادات X.509 للاتصال بالجهاز. تأكد من تنفيذ عمليات معالجة لتحديث الشهادة قبل انتهاء صلاحيتها.
للحصول على أقصى معدل النقل، استخدم الحد الأقصى لعدد الأقسام (32) عند إنشاء IoT Hub، إذا كنت تخطط لاستخدام نقطة النهاية المضمنة. يوضح عدد أقسام الجهاز إلى السحابة لنقطة النهاية المتوافقة مع مركز الأحداث درجة التوازي عند انتقال البيانات من الخادم التي يمكنك تحقيقها. يسمح لك هذا الإجراء بزيادة الحجم إلى 32 من كيانات المعالجة المتزامنة وسيقدم أعلى قابلية وصول لإرسال واستقبال البيانات. لا يمكن تغيير هذا الرقم بعد الإنشاء.
بالنسبة للتحجيم، زِد المستوى وحدات IoT Hub المخصصة بدلاً من إضافة أكثر من IoT Hub لكل منطقة. لا توفر إضافة أكثر من IoT Hub لكل منطقة مرونة إضافية نظراً لإمكانية تشغيل جميع المراكز على نظام المجموعة الأساسي نفسه.
في سيناريوهات معدل النقل العالية، استخدم الأحداث المُنفَذة على دفعات. ستقدم الخدمة صفيفاً بأحداث متعددة للمستهلكين، بدلاً من صفيف بحدث واحد. يجب أن يكون التطبيق المستهلك قادراً على معالجة هذه الصفائف.
إذا كنت تحتاج إلى أقل زمن انتقال ممكن، فلا تستخدم التوجيه واقرأ الأحداث من نقطة النهاية المضمنة. عند استخدام توجيه الرسائل في IoT Hub، يزداد زمن انتقال تسليم الرسالة. في المتوسط، لا ينبغي أن يتجاوز زمن الانتقال 500 ms، ولكن ليس هناك ضمان لزمن انتقال التسليم.
كجزء من إستراتيجية قابلية الوصول على مستوى واسع للحل والإصلاح بعد كارثة، يُرجى مراعاة استخدام خيار استرداد الإصلاح بعد كارثة عبر المناطق في IoT Hub. سينقل هذا الخيار نقطة نهاية IoT Hub إلى منطقة Azure المقترنة. يُنسخ سجل الجهاز فقط. لا تُنسخ الأحداث إلى المنطقة الثانوية. تتراوح مدة هدف وقت الاسترداد (RTO) الخاصة بتجاوز الفشل الذي بدأه العميل بين 10 دقائق إلى بضع ساعات. بالنسبة لتجاوز الفشل الذي بدأته Microsoft، تبلغ RTO 2-26 من الساعات. تأكد من توافق هدف RTO هذا مع متطلبات العميل وإستراتيجية قابلية الوصول الأوسع. إذا كان مطلوباً هدف RTO أعلى، فيُرجى مراعاة تطبيق نمط تجاوز الفشل من جانب العميل.
عند استخدام SDK لإرسال الأحداث إلى IoT Hub، تأكد من الاطلاع على الاستثناءات التي تطرحها سياسة إعادة المحاولة (EventHubsException أو OperationCancelledException) بشكل صحيح. عند استخدام HTTPS، طبِّق نمط إعادة محاولة مناسباً.

الخطوة التالية

IoT Hub والتميز التشغيلي