تدفقات أجهزة مركز IoT (معاينة)
تسهل عمليات دفق أجهزة مركز Azure IoT إنشاء أنفاق TCP آمنة ثنائية الاتجاه لمختلف سيناريوهات الاتصال من سحابة إلى جهاز. يتم التوسط في دفق جهاز بواسطة نقطة نهاية دفق مركز IoT التي تعمل كوكيل بين الجهاز ونقاط تقديم الخدمة. إن هذا الإعداد، الموضح في الرسم التخطيطي أدناه، مفيد بشكل خاص عندما تكون الأجهزة خلف جدار حماية شبكة أو موجودة داخل شبكة خاصة. على هذا النحو، تساعد عمليات دفق أجهزة IoT Hub على معالجة حاجة العملاء للوصول إلى أجهزة IoT بطريقة ملائمة لجدار الحماية ودون الحاجة إلى فتح منافذ جدار حماية الشبكة الواردة أو الصادرة على نطاق واسع.
باستخدام عمليات دفق لجهاز IoT Hub، تظل الأجهزة آمنة وستحتاج فقط إلى فتح اتصالات TCP الصادرة بنقطة نهاية دفق IoT hub عبر المنفذ 443. بمجرد إنشاء عملية دفق، سيكون لكل من التطبيقات من جانب الخدمة ومن جانب الجهاز وصول برمجي إلى عنصر عميل WebSocket لإرسال وحدات البايت البسيطة لبعضها البعض واستقبالها. تتساوى ضمانات الطلب والموثوقية التي يقدمها هذا النفق مع TCP.
المزايا
توفر عمليات دفق أجهزة IoT Hub المزايا التالية:
اتصال آمن ملائم لجدار الحماية: يمكن الوصول إلى أجهزة IoT من نقاط تقديم الخدمة دون فتح منفذ جدار الحماية الوارد في محيط الجهاز أو الشبكة (يلزم الاتصال الصادر فقط بـ IoT Hub عبر المنفذ 443).
المصادقة: تحتاج جوانب الخدمة والجهاز في النفق إلى المصادقة في IoT Hub باستخدام بيانات الاعتماد المقابلة.
التشفير: تستخدم عمليات دفق أجهزة IoT Hub بشكل افتراضي الاتصالات التي تُمكّن TLS. يضمن هذا أن يتم دائماً تشفير نسبة استخدام الشبكة بغض النظر عما إذا كان التطبيق يستخدم التشفير أم لا.
بساطة الاتصال: في كثير من الحالات، فإن استخدام عمليات دفق الأجهزة يلغي الحاجة إلى الإعداد المعقد للشبكات الظاهرية الخاصة لتمكين الاتصال بأجهزة IoT.
التوافق مع مكدس TCP/IP: يمكن أن تستوعب عمليات دفق أجهزة IoT Hub نسبة استخدام الشبكة لتطبيقات TCP/IP. وهذا يعني أن مجموعة واسعة من البروتوكولات الخاصة وكذلك المستندة إلى المعايير يمكن أن تستفيد من هذه الميزة.
سهولة الاستخدام في إعدادات الشبكة الخاصة: يمكن للخدمة الاتصال بجهاز ما عن طريق الرجوع إلى معرّف الجهاز الخاص به، بدلاً من عنوان IP الخاص بالجهاز. هذا مفيد في الحالات التي يوجد فيها جهاز داخل شبكة اتصال خاصة ويحتوي على عنوان IP خاص، أو يتم تعيين عنوان IP الخاص به بشكل ديناميكي ويكون غير معروف من جانب الخدمة.
مهام سير عمل دفق الجهاز
يتم بدء دفق الجهاز عندما تطلب الخدمة الاتصال بجهاز من خلال توفير معرّف الجهاز الخاص به. يتناسب سير العمل هذا بشكل خاص مع نموذج اتصال العميل/الخادم، بما في ذلك SSH وRDP، حيث ينوي المستخدم الاتصال عن بعد بخادم SSH أو RDP الذي يعمل على الجهاز باستخدام برنامج عميل SSH أو RDP.
تتضمن عملية إنشاء دفق الجهاز تفاوضاً بين الجهاز والخدمة ونقاط النهاية الأساسية والمتدفقة لـ IoT hub. بينما تنظم نقطة النهاية الأساسية لـ IoT hub إنشاء دفق الجهاز، فإن نقطة نهاية الدفق تعالج نسبة استخدام الشبكة التي تتدفق بين الخدمة والجهاز.
تدفق إنشاء دفق الجهاز
يتضمن الإنشاء البرمجي لدفق الجهاز باستخدام SDK الخطوات التالية، والتي يتم تصويرها أيضا في الشكل أدناه:
يسجل تطبيق الجهاز رد الاتصال مقدماً ليتم إشعاره عند بدء دفق جهاز جديد على الجهاز. تحدث هذه الخطوة عادةً عند بدء تشغيل الجهاز والاتصال بـ IoT Hub.
يبدأ البرنامج من جانب الخدمة دفق جهاز عند الحاجة عن طريق توفير معرّف الجهاز (وليس عنوان IP).
تعمل IoT hub على إشعار البرنامج من جانب الجهاز عن طريق استدعاء رد الاتصال المسجّل في الخطوة 1. قد يقبل الجهاز طلب بدء الدفق أو يرفضه. يمكن أن يكون هذا المنطق محدداً لسيناريو التطبيق الخاص بك. إذا رفض الجهاز طلب الدفق، تعمل IoT Hub على إبلاغ الخدمة وفقاً لذلك؛ وبخلاف ذلك، اتبع الخطوات أدناه.
يعمل الجهاز على إنشاء اتصال TCP خارجي آمن بنقطة نهاية الدفق عبر المنفذ 443 وترقية الاتصال إلى WebSocket. ءيتم توفير كل من عنوان URL لنقطة نهاية الدفق بالإضافة إلى بيانات الاعتماد لاستخدامها للمصادقة للجهاز بواسطة مركز IoT كجزء من الطلب المرسل في الخطوة 3.
يتم إشعار الخدمة بنتيجة قبول الجهاز للدفق ومتابعة إنشاء عميل WebSocket إلى نقطة نهاية الدفق. وبالمثل، فإنه يتلقى عنوان URL الخاص بنقطة نهاية الدفق ومعلومات المصادقة من IoT Hub.
في عملية تأكيد الاتصال أعلاه:
يجب أن تكتمل عملية تأكيد الاتصال في غضون 60 ثانية (الخطوة من 2 إلى 5)، وإلا ستفشل عملية تأكيد الاتصال مع انتهاء المهلة وسيتم إعلام الخدمة وفقا لذلك.
بعد اكتمال تدفق إنشاء الدفق أعلاه، ستعمل نقطة نهاية الدفق كوكيل وستنقل نسبة استخدام الشبكة بين الخدمة والجهاز عبر WebSockets الخاصة بها.
يحتاج الجهاز والخدمة إلى اتصال صادر بنقطة النهاية الرئيسية لمركز IoT بالإضافة إلى نقطة نهاية الدفق عبر المنفذ 443. يتوفر عنوان URL لنقاط النهاية هذه في علامة التبويب Overview على مدخل مركز IoT.
تكون ضمانات الموثوقية وترتيب التدفق الثابت على قدم المساواة مع TCP.
تستخدم جميع الاتصالات بمركز IoT ونقطة نهاية الدفق TLS ويتم تشفيرها.
تدفق الإنهاء
ينهي الدفق الذي تم إنشاؤه عند قطع اتصال أي من اتصالات TCP بالبوابة (بواسطة الخدمة أو الجهاز). يمكن أن يحدث هذا طوعًا عن طريق إغلاق WebSocket على الجهاز أو برامج الخدمة، أو بشكل غير طوعي في حالة انتهاء مهلة اتصال الشبكة أو فشل العملية. عند إنهاء اتصال الجهاز أو الخدمة بنقطة نهاية الدفق، سيتم أيضًا إنهاء اتصال TCP الآخر (بالقوة) وستكون الخدمة والجهاز مسؤولين عن إعادة إنشاء الدفق، إذا لزم الأمر.
متطلبات الاتصال
يجب أن يكون دفق جهاز من كل من جانب الخدمة والجهاز قادراً على إنشاء اتصالات تُمكن TLS إلى IoT Hub ونقطة نهاية الدفق الخاصة به. يتطلب ذلك اتصالاً صادراً عبر منفذ 443 بنقاط النهاية هذه. يمكن العثور على اسم المضيف المقترن بنقاط النهاية هذه في علامة التبويب نظرة عامة في مركز IoT، كما هو موضح في الشكل أدناه:
بدلًا من ذلك، يمكن استرداد معلومات نقاط النهاية باستخدام Azure CLI ضمن قسم خصائص المركز، وتحديدًا، المفاتيح property.hostname وproperty.deviceStreams.
az iot hub devicestream show --name <YourIoTHubName>
الإخراج هو كائن JSON لجميع نقاط النهاية التي قد يحتاج جهاز المركز والخدمة إلى الاتصال بها من أجل إنشاء دفق الجهاز.
{
"streamingEndpoints": [
"https://<YourIoTHubName>.<region-stamp>.streams.azure-devices.net"
]
}
إشعار
تأكد من تثبيت الإصدار 2.0.57 من Azure CLI أو أحدث. يمكنك تنزيل أحدث إصدار من صفحة تثبيت Azure CLI.
السماح بالاتصال الصادر بنقاط نهاية تدفق الجهاز
كما هو مذكور في بداية هذه المقالة، ينشئ جهازك اتصالًا صادرًا بنقطة نهاية دفق مركز IoT في أثناء عملية بدء تدفقات الجهاز. يجب أن تسمح جدران الحماية على الجهاز أو شبكته بالاتصال الصادر ببوابة البث عبر المنفذ 443 (لاحظ أن الاتصال يتم عبر اتصال WebSocket المشفر باستخدام TLS).
يمكن العثور على اسم مضيف نقطة نهاية تدفق الجهاز على مدخل Azure IoT Hub ضمن علامة التبويب نظرة عامة.
بدلًا من ذلك، يمكنك العثور على هذه المعلومات باستخدام Azure CLI:
az iot hub devicestream show --name <YourIoTHubName>
إشعار
تأكد من تثبيت الإصدار 2.0.57 من Azure CLI أو أحدث. يمكنك تنزيل أحدث إصدار من صفحة تثبيت Azure CLI.
استكشاف الأخطاء وإصلاحها عبر سجلات موارد Device Streams
يمكنك إعداد Azure Monitor لتجميع سجلات الموارد لتدفقات الأجهزة المنبعثة من مركز IoT. يمكن أن يكون هذا مفيدًا جدًا في استكشاف الأخطاء وإصلاحها في السيناريوهات.
اتبع الخطوات أدناه لإنشاء إعداد تشخيص لإرسال سجلات دفق الأجهزة لمركز IoT إلى سجلات Azure Monitor:
في مدخل Microsoft Azure، انتقل إلى مركز IoT. في الجزء الأيسر، ضمن Monitoring، حدد Diagnostic settings. ثم حدد Add diagnostic setting.
أدخل اسمًا لإعداد التشخيص وحدد DeviceStreams من قائمة السجلات. ثم حدد إرسال إلى Log Analytics. سيتم إرشادك لاختيار مساحة عمل Log Analytics موجودة أو إنشاء مساحة عمل جديدة.
بعد إنشاء إعداد تشخيص لإرسال سجلات دفق الجهاز إلى مساحة عمل Log Analytics، يمكنك الوصول إلى السجلات عن طريق تحديد Logs ضمن Monitoring في الجزء الأيمن من مركز IoT في مدخل Microsoft Azure. ستظهر سجلات تدفقات الأجهزة في
AzureDiagnosticsالجدول وسيكون لهاCategory=DeviceStreams. يجب أن تدرك أن الأمر قد يستغرق عدة دقائق بعد عملية للسجلات لتظهر في الجدول.كما هو موضح أدناه، تتوفر أيضًا هوية الجهاز الهدف ونتيجة العملية في السجلات.
لمعرفة المزيد حول استخدام Azure Monitor مع مركز IoT، راجع Monitor IoT Hub. للحصول على معلومات حول جميع سجلات الموارد والمقاييس والجداول المتوفرة لمركز IoT، راجع مراقبة مرجع بيانات مركز Azure IoT.
التوفر الإقليمي
أثناء المعاينة العامة، تتوفر تدفقات أجهزة IoT Hub في مناطق وسط الولايات المتحدة وشرق الولايات المتحدة EUAP وشمال أوروبا وجنوب شرق آسيا. الرجاء التأكد من إنشاء مركزك في إحدى هذه المناطق.
توفر SDK
يستخدم وجهان لكل دفق (على جانب الجهاز والخدمة) مركز IoT SDK لإنشاء النفق. في أثناء المعاينة العامة، يمكن للعملاء الاختيار من بين لغات SDK التالية:
يتدفق جهاز دعم C وC# SDK على جانب الجهاز.
يدعم NodeJS وC# SDK تدفقات الجهاز على جانب الخدمة.
الخطوات التالية
استخدم الارتباطات أدناه لمعرفة المزيد حول تدفقات الأجهزة.