إدارة الاتصال والمراسلة الموثوقة باستخدام مجموعات SDK لأجهزة Azure IoT Hub
توفر هذه المقالة إرشادات عالية المستوى لمساعدتك في تصميم تطبيقات الأجهزة الأكثر مرونة. يوضح لك كيفية الاستفادة من ميزات الاتصال والمراسلة الموثوقة في مجموعات SDK لأجهزة Azure IoT. الهدف من هذا الدليل هو مساعدتك في إدارة السيناريوهات التالية:
إصلاح اتصال شبكة مُنقطع
التبديل بين توصيلات شبكة اتصال مختلفة
إعادة التوصيل بسبب أخطاء توصيل عارضة لللخدمة
قد تختلف تفاصيل التنفيذ حسب اللغة. لمزيد من المعلومات، راجع وثائق واجهة برمجة التطبيقات أو SDK محددة:
Python SDK (الموثوقية لم تنفذ بعد)
تصميم المرونة
تعتمد أجهزة IoT غالبا على توصيلات شبكة غير مستمرة أو غير مستقرة (على سبيل المثال، GSM أو القمر الصناعي). قد تحدث أخطاء عندما تتفاعل الأجهزة مع الخدمات المستندة إلى شبكة النظير بسبب توفّر الخدمة المتقطعة والأخطاء على مستوى البنية التحتية أو الأخطاء العابرة. يجب على التطبيق الذي يعمل على جهاز إدارة آليات الاتصال وإعادة الاتصال ومنطق إعادة المحاولة لإرسال الرسائل وتلقيها. كما تعتمد متطلبات استراتيجية إعادة المحاولة بشكل كبير على سيناريو IoT للجهاز والسياق والقدرات.
تهدف أجهزة SDK الخاصة بجهاز Microsoft Azure IoT Hub إلى تبسيط التوصيل والاتصال من شبكة النظير إلى الجهاز ومن الجهاز إلى شبكة النظير. توفّر SDKs هذه طريقة قوية للاتصال بجهاز Microsoft Azure IoT Hub ومجموعة شاملة من الخيارات لإرسال الرسائل واستقبالها. كما يمكن للمطورين تعديل التطبيق الحالي لتخصيص استراتيجية إعادة محاولة أفضل لسيناريو معين.
يتم تغطية ميزات SDK ذات الصلة التي تدعم الاتصال والمراسلة الموثوقة في الأقسام التالية.
التوصيل وإعادة المحاولة
يقدم هذا القسم نظرة عامة على أنماط إعادة الاتصال وإعادة المحاولة المتوفرة عند إدارة الاتصالات. وهو يفصّل إرشادات التنفيذ لاستخدام نهج إعادة محاولة مختلف في تطبيق جهازك ويسرد واجهات برمجة التطبيقات ذات الصلة من SDKs الخاصة بالجهاز.
أنماط متعلقة بالأخطاء
قد تحدث عمليات فشل التوصيل على مستويات عديدة:
أخطاء الشبكة: أخطاء دقة الاسم ومأخذ التوصيل المنفصل
أخطاء مستوى البروتوكول لـ HTTP و AMQP و MQTT: ارتباطات تشعبية منفصلة أو جلسات منتهية الصلاحية
أخطاء على مستوى التطبيق والتي تنتج عن الأخطاء المحلية: بيانات اعتماد غير صالحة أو سلوك الخدمة (على سبيل المثال، تجاوز الحصة النسبية أو التقييد)
تكتشف SDKs الموجودة بالجهاز الأخطاء على جميع المستويات الثلاثة. لا يتم الكشف عن الأخطاء المتعلقة بنظام التشغيل والأخطاء المتعلقة بالأجهزة ومعالجتها من SDKs الموجودة بالجهاز. يستند تصميم SDK إلى إرشادات معالجة الأخطاء العابرة من مركز بنية Azure.
أنماط إعادة المحاولة
تصف الخطوات التالية عملية إعادة المحاولة عند الكشف عن أخطاء التوصيل:
تكشف SDK عن الخطأ والخطأ المقترن في شبكة الاتصال أو البروتوكول أو التطبيق.
تستخدم SDK عامل تصفية الأخطاء لتحديد نوع الخطأ ثم تحديد ما إذا كانت هناك حاجة إلى إعادة المحاولة.
إذا حددت SDK خطأ غير قابل للاسترداد، إيقاف عمليات مثل الاتصال والإرسال والاستقبال. تُخطر SDK المستخدم. تتضمن أمثلة الأخطاء غير القابلة للاسترداد خطأ مصادقة وخطأ نقطة نهاية غير صالح.
إذا حددت SDK خطأ قابلا للاسترداد، فستعيد المحاولة وفقا لنهج إعادة المحاولة المحدد حتى تنقضي المهلة المحددة. لاحظ أن SDK تستخدم التراجع الأسي مع سياسة إعادة محاولة التوتر بشكل افتراضي.
عند انتهاء المهلة المحددة، تتوقف SDK عن محاولة التوصيل أو الإرسال. فإنه يُخطر المستخدم.
تسمح SDK للمستخدم بإرفاق رد اتصال لتلقي تغييرات حالة التوصيل.
توفر SDKs ثلاثة نهج لإعادة المحاولة:
التراجع الأسي مع القلق: تميل سياسة إعادة المحاولة الافتراضية هذه إلى أن تكون عدوانية في البداية وتتباطأ بمرور الوقت حتى تصل إلى أقصى قدر من التأخير. يعتمد التصميم على إرشادات إعادة المحاولة من مركز بنية Azure.
إعادة المحاولة المخصصة: بالنسبة لبعض لغات SDK، يمكنك تصميم نهج إعادة محاولة مخصص أكثر ملاءمة للسيناريو الخاص بك ثم حقنه في سياسة إعادة المحاولة. لا تتوفر إعادة المحاولة المخصصة على C SDK، وهي غير مدعومة حاليا على حزمة Python SDK. تقوم Python SDK بإعادة الاتصال حسب الحاجة.
عدم إعادة المحاولة: يمكنك تعيين نهج إعادة المحاولة إلى "عدم إعادة المحاولة"، مما يؤدي إلى تعطيل منطق إعادة المحاولة. تحاول SDK الاتصال مرة واحدة وإرسال رسالة مرة واحدة، على افتراض تأسيس التوصيل. يُستخدم هذا النهج عادة في سيناريوهات ذات عرض النطاق الترددي أو المخاوف المتعلقة بالتكلفة. إذا اخترت هذا الخيار، تُفقد الرسائل التي تفشل في إرسالها ولا يمكن استردادها.
واجهة برمجة تطبيقات نهج إعادة المحاولة
| SDK | تعيين وسيلة إعادة المحاولة | عمليات تنفيذ النهج | إرشادات التنفيذ |
|---|---|---|---|
| C/iOS | IOTHUB_CLIENT_RESULT IoTHubClient_SetRetryPolicy | الافتراضي: IOTHUB_CLIENT_RETRY_EXPONENTIAL_BACKOFF مخصص: استخدم سياسة إعادة المحاولة المتاحة لا توجد إعادة محاولة:IOTHUB_CLIENT_RETRY_NONE |
تنفيذ C/iOS |
| Java | تعيين نهج إعادة المحاولة | الافتراضي: الفئة الأسيةBackoffWithJitter مخصص: تنفيذ واجهة RetryPolicy لا توجد إعادة محاولة:فئة NoRetry |
تنفيذ Java |
| .NET | نهج إعادة المحاولة لجهاز العميل | الافتراضي: الفئة الأسية الاحتياطية مخصص: تنفيذ واجهة IRetryPolicy لا توجد إعادة محاولة:فئة NoRetry |
تنفيذ C# |
| Node | عيّن نهج إعادة المحاولة | الافتراضي: الفئة الأسيةBackoffWithJitter | التنفيذ العُقدي |
| Python | غير مدعوم في الوقت الحالي | غير مدعوم في الوقت الحالي | غير مدعوم في الوقت الحالي |
توضح نماذج التعليمات البرمجية التالية هذا التدفق:
توجيهات تنفيذ Microsoft .NET
يوضح نموذج التعليمات البرمجية التالي كيفية تحديد نهج إعادة المحاولة الافتراضي وتوصيله:
// define/set default retry policy
IRetryPolicy retryPolicy = new ExponentialBackoff(int.MaxValue, TimeSpan.FromMilliseconds(100), TimeSpan.FromSeconds(10), TimeSpan.FromMilliseconds(100));
SetRetryPolicy(retryPolicy);
لتجنب استخدام معالج عالي، يتم تقييد إعادة المحاولة إذا فشلت التعليمات البرمجية مباشرة. على سبيل المثال، عندما لا توجد شبكة أو مسار إلى موفّر الوجهة. يكون الحد الأدنى من الوقت لتنفيذ إعادة المحاولة التالية هو ثانية واحدة (1).
إذا كانت الخدمة تستجيب مع خطأ تقييد، يكون نهج إعادة المحاولة مختلفا ولا يمكن تغييره عبر واجهة برمجة التطبيقات العامة:
// throttled retry policy
IRetryPolicy retryPolicy = new ExponentialBackoff(RetryCount, TimeSpan.FromSeconds(10),
TimeSpan.FromSeconds(60), TimeSpan.FromSeconds(5)); SetRetryPolicy(retryPolicy);
تتوقف آلية إعادة المحاولة بعد DefaultOperationTimeoutInMillisecondsذلك ، والتي يتم تعيينها حاليا في 4 دقائق.
إرشادات تنفيذ اللغات الأخرى
للحصول على نماذج التعليمات البرمجية بلغات أخرى، راجع مستندات التنفيذ التالية. يحتوي المستودع على عينات توضح استخدام واجهات برمجة تطبيقات نهج إعادة المحاولة.
Python SDK (الموثوقية لم تنفذ بعد)