Zarządzanie ponownymi połączeniami urządzeń w celu tworzenia odpornych aplikacji

Artykuł
10/17/2024

Ten artykuł zawiera ogólne wskazówki ułatwiające projektowanie odpornych aplikacji przez dodanie strategii ponownego łączenia urządzenia. Wyjaśnia, dlaczego urządzenia rozłączą się i muszą ponownie nawiązać połączenie. Opisano w nim konkretne strategie, których deweloperzy mogą używać do ponownego łączenia urządzeń, które zostały odłączone.

Co powoduje rozłączenia

Poniżej przedstawiono najczęstsze przyczyny rozłączenia urządzeń z usługą IoT Hub:

Wygasły token SAS lub certyfikat X.509. Token SAS urządzenia lub certyfikat uwierzytelniania X.509 wygasł.
Przerwy w działaniu sieci. Połączenie urządzenia z siecią zostanie przerwane.
Przerwy w działaniu usługi. Usługa Azure IoT Hub napotyka błędy lub jest tymczasowo niedostępna.
Ponowna konfiguracja usługi. Po ponownym skonfigurowaniu ustawień usługi IoT Hub może to spowodować, że urządzenia będą wymagać ponownej aprowizacji lub ponownego nawiązania połączenia.

Dlaczego potrzebujesz strategii ponownego łączenia

Ważne jest, aby mieć strategię ponownego łączenia urządzeń zgodnie z opisem w poniższych sekcjach. Bez strategii ponownego łączenia można zobaczyć negatywny wpływ na wydajność, dostępność i koszty rozwiązania.

Próby ponownego nawiązania połączenia masowego mogą spowodować atak DDoS

Duża liczba prób połączenia na sekundę może spowodować stan podobny do rozproszonego ataku typu „odmowa usługi” (DDoS). Ten scenariusz jest odpowiedni dla dużych flot urządzeń liczonych w milionach. Problem może wykraczać poza dzierżawę będącą właścicielem floty i wpływać na całą jednostkę skalowania. Usługa DDoS może zwiększyć koszty dla zasobów usługi Azure IoT Hub ze względu na konieczność skalowania w poziomie. Atak DDoS może również zaszkodzić wydajności rozwiązania z powodu niedoboru zasobów. W najgorszym przypadku atak DDoS może spowodować przerwę w działaniu usługi.

Awaria koncentratora lub ponowna konfiguracja może spowodować rozłączenie wielu urządzeń

Po wystąpieniu awarii centrum IoT lub po ponownym skonfigurowaniu ustawień usługi w centrum IoT urządzenia mogą zostać odłączone. W przypadku odpowiedniego przejścia w tryb failover odłączone urządzenia wymagają ponownej aprowizacji. Aby dowiedzieć się więcej na temat opcji trybu failover, zobacz Wysoka dostępność i odzyskiwanie po awarii usługi IoT Hub.

Ponowne aprowizowanie wielu urządzeń może zwiększyć koszty

Po rozłączeniu urządzeń z usługą IoT Hub optymalne rozwiązanie polega na ponownym połączeniu urządzenia, a nie ponownym aprowizacji. Jeśli używasz usługi IoT Hub z usługą DPS, usługa DPS ma koszt aprowizacji. Jeśli ponownie aprowizujesz wiele urządzeń w usłudze DPS, zwiększa to koszt rozwiązania IoT. Aby dowiedzieć się więcej na temat kosztów aprowizacji usługi DPS, zobacz Cennik usługi IoT Hub DPS.

Projektowanie pod kątem odporności

Urządzenia IoT często korzystają z niekontynuacyjnych lub niestabilnych połączeń sieciowych (na przykład GSM lub satelity). Błędy mogą wystąpić, gdy urządzenia wchodzą w interakcje z usługami opartymi na chmurze z powodu sporadycznych dostępności usług i błędów na poziomie infrastruktury lub przejściowych. Aplikacja działająca na urządzeniu musi zarządzać mechanizmami połączenia, ponownego łączenia i logiki ponawiania prób wysyłania i odbierania komunikatów. Ponadto wymagania dotyczące strategii ponawiania zależą w dużym stopniu od scenariusza IoT urządzenia, kontekstu, możliwości.

Zestawy SDK urządzeń usługi Azure IoT Hub mają na celu uproszczenie łączenia się i komunikowania się z chmury do urządzenia i z urządzenia do chmury. Te zestawy SDK zapewniają niezawodny sposób nawiązywania połączenia z usługą Azure IoT Hub oraz kompleksowy zestaw opcji wysyłania i odbierania komunikatów. Deweloperzy mogą również modyfikować istniejącą implementację, aby dostosować lepszą strategię ponawiania prób dla danego scenariusza.

Odpowiednie funkcje zestawu SDK, które obsługują łączność i niezawodne komunikaty, są dostępne w następujących zestawach SDK urządzeń usługi IoT Hub. Aby uzyskać więcej informacji, zobacz dokumentację interfejsu API lub określony zestaw SDK:

W poniższych sekcjach opisano funkcje zestawu SDK, które obsługują łączność.

Połączenie i ponów próbę

Ta sekcja zawiera omówienie wzorców ponownego nawiązywania połączenia i ponawiania prób dostępnych podczas zarządzania połączeniami. Zawiera on szczegółowe wskazówki dotyczące implementacji dotyczące używania innych zasad ponawiania prób w aplikacji urządzenia i zawiera listę odpowiednich interfejsów API z zestawów SDK urządzeń.

Wzorce błędów

Błędy połączeń mogą wystąpić na wielu poziomach:

Błędy sieci: błędy rozłączenia gniazda i rozpoznawania nazw
Błędy na poziomie protokołu dla transportu HTTP, AMQP i MQTT: odłączone łącza lub wygasłe sesje
Błędy na poziomie aplikacji, które wynikają z błędów lokalnych: nieprawidłowe poświadczenia lub zachowanie usługi (na przykład przekroczenie limitu przydziału lub ograniczanie przepustowości)

Zestawy SDK urządzeń wykrywają błędy na wszystkich trzech poziomach. Jednak zestawy SDK urządzeń nie wykrywają i nie obsługują błędów związanych z systemem operacyjnym i błędów sprzętowych. Projekt zestawu SDK jest oparty na wskazówkach dotyczących obsługi błędów przejściowych z Centrum architektury platformy Azure.

Wzorce ponawiania

W poniższych krokach opisano proces ponawiania próby po wykryciu błędów połączenia:

Zestaw SDK wykrywa błąd i skojarzony błąd w sieci, protokole lub aplikacji.
Zestaw SDK używa filtru błędów, aby określić typ błędu i zdecydować, czy jest wymagana ponowna próba.
Jeśli zestaw SDK zidentyfikuje nieodwracalny błąd, operacje takie jak połączenie, wysyłanie i odbieranie zostaną zatrzymane. Zestaw SDK powiadamia użytkownika. Przykłady nieodwracalnych błędów obejmują błąd uwierzytelniania i nieprawidłowy błąd punktu końcowego.
Jeśli zestaw SDK zidentyfikuje błąd możliwy do odzyskania, ponawia próbę zgodnie z określonymi zasadami ponawiania do momentu upływu zdefiniowanego limitu czasu. Zestaw SDK domyślnie używa wycofywania wykładniczego z zasadami ponawiania prób.
Po wygaśnięciu zdefiniowanego limitu czasu zestaw SDK przestaje próbować nawiązać połączenie lub wysłać. Powiadamia użytkownika.
Zestaw SDK umożliwia użytkownikowi dołączanie wywołania zwrotnego w celu odbierania zmian stanu połączenia.

Zestawy SDK zwykle udostępniają trzy zasady ponawiania prób:

Wykładne wycofywanie z zakłóceniami: ta domyślna zasada ponawiania prób zwykle jest agresywna na początku i spowalnia w czasie, aż osiągnie maksymalne opóźnienie. Projekt jest oparty na wskazówkach dotyczących ponawiania prób z Centrum architektury platformy Azure.
Niestandardowe ponawianie: w przypadku niektórych języków zestawu SDK można zaprojektować niestandardowe zasady ponawiania, które są lepiej odpowiednie dla danego scenariusza, a następnie wprowadzić je do zasad RetryPolicy. Niestandardowe ponawianie nie jest dostępne w zestawie SDK języka C i nie jest obecnie obsługiwane w zestawie SDK języka Python. Zestaw SDK języka Python ponownie łączy się zgodnie z potrzebami.
Brak ponawiania: można ustawić zasady ponawiania prób na "bez ponawiania", co powoduje wyłączenie logiki ponawiania. Zestaw SDK próbuje nawiązać połączenie raz i wysłać komunikat jeden raz, zakładając, że połączenie zostało nawiązane. Te zasady są zwykle używane w scenariuszach związanych z przepustowością lub kosztami. Jeśli wybierzesz tę opcję, komunikaty, których nie można wysłać, zostaną utracone i nie można ich odzyskać.

Interfejsy API zasad ponawiania prób

SDK	SetRetryPolicy, metoda	Implementacje zasad	Wskazówki dotyczące implementacji
C	IOTHUB_CLIENT_RESULT IoTHubDeviceClient_SetRetryPolicy	Zobacz: IOTHUB_CLIENT_RETRY_POLICY	Implementacja języka C
Java	SetRetryPolicy	Ustawienie domyślne: ExponentialBackoffWithJitter, klasa Niestandardowe: implementowanie interfejsu RetryPolicy Brak ponawiania próby: NoRetry, klasa	Implementacja języka Java
.NET	DeviceClient.SetRetryPolicy	Ustawienie domyślne: ExponentialBackoff, klasa Niestandardowe: implementowanie interfejsu IRetryPolicy Brak ponawiania próby: NoRetry, klasa	Implementacja języka C#
Węzeł	setRetryPolicy	Ustawienie domyślne: ExponentialBackoffWithJitter, klasa Niestandardowe: implementowanie interfejsu RetryPolicy Brak ponawiania próby: NoRetry, klasa	Implementacja węzła
Python	Obecnie nieobsługiwane	Obecnie nieobsługiwane	Wbudowane ponawianie prób połączenia: połączenia porzucone są domyślnie ponawiane z stałym interwałem 10 sekund. Tę funkcję można wyłączyć w razie potrzeby, a interwał można skonfigurować.

Przepływ ponownego łączenia koncentratora

Jeśli używasz usługi IoT Hub tylko bez usługi DPS, użyj następującej strategii ponownego nawiązywania połączenia.

Gdy urządzenie nie może nawiązać połączenia z usługą IoT Hub lub zostanie rozłączone z usługą IoT Hub:

Użyj wycofywania wykładniczego z funkcją opóźnienia trzęsące.
Połącz się ponownie z usługą IoT Hub.

Na poniższym diagramie przedstawiono podsumowanie przepływu ponownego łączenia:

Diagram przepływu ponownego łączenia urządzenia dla usługi IoT Hub.

Koncentrator z przepływem ponownego nawiązywania połączenia z usługą DPS

Jeśli używasz usługi IoT Hub z usługą DPS, użyj następującej strategii ponownego nawiązywania połączenia.

Jeśli urządzenie nie może nawiązać połączenia z usługą IoT Hub lub zostanie odłączone od usługi IoT Hub, połącz się ponownie w następujących przypadkach:

Scenariusz ponownego nawiązywania połączenia	Strategia ponownego łączenia
W przypadku błędów, które zezwalają na ponawianie prób połączenia (kod odpowiedzi HTTP 500)	Użyj wycofywania wykładniczego z funkcją opóźnienia trzęsące. Połącz się ponownie z usługą IoT Hub.
W przypadku błędów wskazujących, że ponowna próba jest możliwa, ale ponowne nawiązanie połączenia nie powiodło się 10 kolejnych razy	Ponownie aprowizacja urządzenia w usłudze DPS.
W przypadku błędów, które nie zezwalają na ponawianie prób połączenia (odpowiedzi HTTP 401, Brak autoryzacji lub 403, Zabronione lub 404, Nie znaleziono)	Ponownie aprowizacja urządzenia w usłudze DPS.