إدارة عمليات إعادة توصيل الجهاز لإنشاء تطبيقات مرنة
توفر هذه المقالة إرشادات عالية المستوى لمساعدتك في تصميم تطبيقات مرنة عن طريق إضافة استراتيجية إعادة توصيل الجهاز. وهو يشرح سبب قطع اتصال الأجهزة والحاجة إلى إعادة الاتصال. وهو يصف استراتيجيات محددة يمكن للمطورين استخدامها لإعادة توصيل الأجهزة التي تم قطع اتصالها.
ما الذي يسبب قطع الاتصال
فيما يلي الأسباب الأكثر شيوعا لقطع اتصال الأجهزة ب IoT Hub:
- رمز SAS المميز منتهية الصلاحية أو شهادة X.509. انتهت صلاحية رمز SAS المميز للجهاز أو شهادة مصادقة X.509.
- انقطاع الشبكة. تمت مقاطعة اتصال الجهاز بالشبكة.
- تعطيل الخدمة. تواجه خدمة Azure IoT Hub أخطاء أو غير متوفرة مؤقتا.
- إعادة تكوين الخدمة. بعد إعادة تكوين إعدادات خدمة IoT Hub، يمكن أن يتسبب ذلك في مطالبة الأجهزة بإعادة التزويد أو إعادة الاتصال.
لماذا تحتاج إلى استراتيجية إعادة الاتصال
من المهم أن يكون لديك استراتيجية لإعادة توصيل الأجهزة كما هو موضح في الأقسام التالية. بدون استراتيجية إعادة الاتصال، قد ترى تأثيرا سلبيا على أداء الحل وتوافره وتكلفته.
يمكن أن تتسبب محاولات إعادة الاتصال الجماعية في DDoS
يمكن أن يتسبب عدد كبير من محاولات الاتصال في الثانية في حالة مشابهة لهجوم موزع لحجب الخدمة (DDoS). هذا السيناريو ذو صلة بالأساطيل الكبيرة من الأجهزة التي يتم ترقيمها بالملايين. يمكن أن تمتد المشكلة إلى ما هو أبعد من المستأجر الذي يمتلك الأسطول، وتؤثر على وحدة المقياس بأكملها. يمكن أن يؤدي DDoS إلى زيادة كبيرة في التكلفة لموارد Azure IoT Hub، بسبب الحاجة إلى التوسع. يمكن أن يضر DDoS أيضا بأداء الحل الخاص بك بسبب تجويع الموارد. في الحالة الأسوأ، يمكن أن يتسبب DDoS في انقطاع الخدمة.
قد يؤدي فشل المركز أو إعادة تكوينه إلى قطع اتصال العديد من الأجهزة
بعد أن يواجه مركز IoT فشلا، أو بعد إعادة تكوين إعدادات الخدمة على مركز IoT، قد يتم قطع اتصال الأجهزة. لتجاوز الفشل المناسب، تتطلب الأجهزة غير المتصلة إعادة التزويد. لمعرفة المزيد حول خيارات تجاوز الفشل، راجع التوفر العالي ل IoT Hub والتعافي من الكوارث.
يمكن أن تؤدي إعادة توفير العديد من الأجهزة إلى زيادة التكاليف
بعد قطع اتصال الأجهزة ب IoT Hub، يكون الحل الأمثل هو إعادة توصيل الجهاز بدلا من إعادة تزويده. إذا كنت تستخدم IoT Hub مع DPS، فإن DPS لها تكلفة توفير لكل. إذا قمت بإعادة توفير العديد من الأجهزة على DPS، فإنه يزيد من تكلفة حل IoT الخاص بك. لمعرفة المزيد حول تكاليف توفير DPS، راجع تسعير IoT Hub DPS.
تصميم للمرونة
غالبا ما تعتمد أجهزة IoT على اتصالات الشبكة غير المتصلة أو غير المستقرة (على سبيل المثال، GSM أو القمر الصناعي). قد تحدث أخطاء عندما تتفاعل الأجهزة مع الخدمات المستندة إلى شبكة النظير بسبب توفّر الخدمة المتقطعة والأخطاء على مستوى البنية التحتية أو الأخطاء العابرة. تطبيق يعمل على جهاز له القدرة على إدارة آليات التوصيل وإعادة التوصيل ومنطق إعادة المحاولة لإرسال الرسائل واستقبالها. كما تعتمد متطلبات استراتيجية إعادة المحاولة بشكل كبير على سيناريو IoT للجهاز والسياق والقدرات.
تهدف أجهزة SDK الخاصة بجهاز Microsoft Azure IoT Hub إلى تبسيط التوصيل والاتصال من شبكة النظير إلى الجهاز ومن الجهاز إلى شبكة النظير. توفّر SDKs هذه طريقة قوية للاتصال بجهاز Microsoft Azure IoT Hub ومجموعة شاملة من الخيارات لإرسال الرسائل واستقبالها. كما يمكن للمطورين تعديل التطبيق الحالي لتخصيص استراتيجية إعادة محاولة أفضل لسيناريو معين.
تتوفر ميزات SDK ذات الصلة التي تدعم الاتصال والمراسلة الموثوق بها في SDKs لجهاز IoT Hub التالي. لمزيد من المعلومات، راجع وثائق واجهة برمجة التطبيقات أو SDK محددة:
تصف الأقسام التالية ميزات 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 | IOTHUB_CLIENT_RESULT IoTHubDeviceClient_SetRetryPolicy | راجع: IOTHUB_CLIENT_RETRY_POLICY | تنفيذ C |
| Java | تعيين نهج إعادة المحاولة | الافتراضي: فئة ExponentialBackoffWithJitter مخصص: تنفيذ واجهة RetryPolicy لا توجد إعادة محاولة:فئة NoRetry |
تنفيذ Java |
| .NET | DeviceClient.SetRetryPolicy | الافتراضي: فئة النسخ الاحتياطي الأسي مخصص: تنفيذ واجهة IRetryPolicy لا توجد إعادة محاولة:فئة NoRetry |
تنفيذ C# |
| العقدة | تعيين نهج إعادة المحاولة | الافتراضي: فئة ExponentialBackoffWithJitter مخصص: تنفيذ واجهة RetryPolicy لا توجد إعادة محاولة:فئة NoRetry |
تنفيذ العقدة |
| Python | غير مدعوم حاليًا | غير مدعوم حاليًا | إعادة محاولة الاتصال المضمنة: تتم إعادة محاولة الاتصالات التي تم إسقاطها بفاصل زمني ثابت مدته 10 ثوان بشكل افتراضي. يمكن تعطيل هذه الوظيفة إذا رغبت في ذلك، ويمكن تكوين الفاصل الزمني. |
تدفق إعادة اتصال المركز
إذا كنت تستخدم IoT Hub فقط بدون DPS، فاستخدم استراتيجية إعادة الاتصال التالية.
عندما يفشل جهاز في الاتصال ب IoT Hub، أو يتم قطع اتصاله ب IoT Hub:
- استخدم التراجع الأسي مع دالة تأخير التشويه.
- إعادة الاتصال ب IoT Hub.
يلخص الرسم التخطيطي التالي تدفق إعادة الاتصال:
المركز مع تدفق إعادة اتصال DPS
إذا كنت تستخدم IoT Hub مع DPS، فاستخدم استراتيجية إعادة الاتصال التالية.
عندما يفشل جهاز في الاتصال ب IoT Hub، أو يتم قطع اتصاله ب IoT Hub، أعد الاتصال استنادا إلى الحالات التالية:
| سيناريو إعادة الاتصال | استراتيجية إعادة الاتصال |
|---|---|
| للأخطاء التي تسمح بإعادة محاولة الاتصال (رمز استجابة HTTP 500) | استخدم التراجع الأسي مع دالة تأخير التشويه. إعادة الاتصال ب IoT Hub. |
| بالنسبة للأخطاء التي تشير إلى إمكانية إعادة المحاولة، ولكن فشلت إعادة الاتصال 10 مرات متتالية | إعادة توفير الجهاز إلى DPS. |
| بالنسبة للأخطاء التي لا تسمح بإعادة محاولة الاتصال (استجابات HTTP 401 أو غير مصرح به أو 403 أو ممنوع أو 404، غير موجود) | إعادة توفير الجهاز إلى DPS. |
يلخص الرسم التخطيطي التالي تدفق إعادة الاتصال:
الخطوات التالية
تتضمن الخطوات التالية المقترحة ما يلي: