Spostare una soluzione basata su hub IoT da test a produzione
Questo articolo fornisce un elenco di considerazioni chiave per la transizione di una soluzione basata su hub IoT di Azure a un ambiente di produzione.
Usare stamp di distribuzione
I francobolli di distribuzione sono unità discrete di componenti principali della soluzione che supportano un numero definito di dispositivi. Una singola unità è nota come stamp o unità di scala. Un timbro può essere costituito da un popolamento di dispositivi impostato, un hub IoT, un hub eventi o un altro endpoint di routing e un componente di elaborazione. Ogni stamp supporta un popolamento dei dispositivi definiti. Si sceglie il numero massimo di dispositivi che il timbro può contenere. Man mano che il popolamento dei dispositivi aumenta, si aggiungono istanze di stamp anziché aumentare in modo indipendente le diverse parti della soluzione.
Se si sposta una singola istanza della soluzione basata sull'hub IoT nell'ambiente di produzione anziché aggiungere stamp, è possibile che si verifichino le limitazioni seguenti:
Limiti di scalabilità. La singola istanza può riscontrare limiti di ridimensionamento. Ad esempio, la soluzione potrebbe usare servizi con limiti per il numero di connessioni in ingresso, nomi host, socket del protocollo di controllo di trasmissione o altre risorse.
Scalabilità non lineare o costo. I componenti della soluzione potrebbero non essere ridimensionati in modo lineare con il numero di richieste o il volume di dati inseriti. Alcuni componenti potrebbero invece riscontrare una riduzione delle prestazioni o un aumento dei costi dopo il raggiungimento di una soglia. In questi casi, l'aumento del numero di istanze aggiungendo indicatori potrebbe essere una strategia più efficace rispetto all'aumento della capacità.
Separazione dei clienti. Potrebbe essere necessario isolare dati specifici dei clienti dai dati di altri clienti. È possibile raggruppare i clienti che hanno esigenze di risorse più elevate su timbri diversi.
Istanze a tenant singolo e multi-tenant. Potrebbero essere presenti diversi clienti di grandi dimensioni che necessitano delle proprie istanze indipendenti della soluzione. In alternativa, potrebbe essere disponibile un pool di clienti più piccoli che possono condividere una distribuzione multi-tenant.
Requisiti di distribuzione complessi. Potrebbe essere necessario distribuire gli aggiornamenti al servizio in modo controllato e distribuirlo in timbri diversi in momenti diversi.
Frequenza di aggiornamento. È possibile che i clienti siano tolleranti degli aggiornamenti frequenti del sistema, mentre altri clienti potrebbero essere a rischio e vogliono aggiornamenti poco frequenti al servizio.
Restrizioni geografiche o geopolitiche. Per ridurre la latenza o rispettare i requisiti di sovranità dei dati, è possibile distribuire alcuni clienti in aree specifiche.
Per evitare i problemi precedenti, è consigliabile raggruppare il servizio in più francobolli. Gli stamp operano autonomamente l'uno dall'altro e possono essere distribuiti e aggiornati in modo indipendente. Una singola area geografica può contenere un singolo timbro o contenere più timbri per abilitare la scalabilità orizzontale all'interno dell'area. Ogni stamp contiene un subset dei clienti.
Per altre informazioni, vedere Modello stamp di distribuzione.
Usare il backoff quando si verifica un errore temporaneo
Tutte le applicazioni che comunicano con servizi remoti e risorse devono essere progettate per gestire gli errori temporanei. Questa esigenza è particolarmente cruciale negli ambienti cloud, in cui la connettività aumenta la probabilità di riscontrare questi errori. Gli errori temporanei includono:
- Perdita momentanea della connettività di rete ai componenti e ai servizi.
- Indisponibilità temporanea di un servizio.
- Timeout che si verificano quando un servizio è occupato.
- Collisioni che si verificano quando i dispositivi trasmettono simultaneamente.
Questi errori sono spesso autocorribili e, se l'azione viene ripetuta dopo un ritardo appropriato, è probabile che abbia esito positivo. Tuttavia, determinare gli intervalli appropriati tra i tentativi è difficile. Le strategie più comuni usano i tipi di intervallo tra tentativi seguenti:
Backoff esponenziale. L'applicazione attende un breve periodo di tempo prima del primo tentativo, quindi aumenta progressivamente il tempo di attesa tra i tentativi successivi. Ad esempio, potrebbe ritentare l'operazione dopo 3 secondi, 12 secondi o 30 secondi.
Intervalli regolari. L'applicazione attende lo stesso intervallo di tempo prima di ripetere ogni nuovo tentativo. Ad esempio, potrebbe ritentare l'operazione ogni 3 secondi.
Riprovare immediatamente. A volte un errore temporaneo è breve e può verificarsi a causa di eventi come un conflitto di pacchetti di rete o un picco in un componente hardware. In questo scenario, ripetere immediatamente l'operazione è appropriato. Se l'errore viene cancellato dal momento in cui l'applicazione viene assemblata e inviata la richiesta successiva, l'operazione può avere esito positivo. Tuttavia, non dovrebbe mai esserci più di un tentativo immediato. Se il nuovo tentativo immediato ha esito negativo, passare a strategie alternative, ad esempio azioni di back-off esponenziale o di fallback.
Randomizzazione. Una delle strategie di ripetizione dei tentativi precedenti può includere un elemento di randomizzazione per impedire a più istanze del client di inviare tentativi successivi contemporaneamente.
Evitare i seguenti anti-pattern:
Non includere livelli duplicati di codice di ripetizione dei tentativi nelle implementazioni.
Non implementare mai un meccanismo a ciclo infinito.
Non eseguire mai un nuovo tentativo immediato più di una volta.
Evitare di usare un intervallo regolare di ripetizione dei tentativi.
Impedire a più istanze dello stesso client o a più istanze di client diversi di inviare nuovi tentativi contemporaneamente.
Per altre informazioni, vedere Gestione degli errori temporanei.
Usare il provisioning completamente automatico
Il provisioning è il processo di registrazione di un dispositivo nell'hub IoT. Il provisioning registra un dispositivo con l'hub IoT e specifica il meccanismo di attestazione usato. È possibile usare il servizio Device Provisioning in hub IoT (DPS) o effettuare il provisioning direttamente tramite le API di Gestione registro dell'hub IoT. L'uso del servizio Device Provisioning offre il vantaggio dell'associazione tardiva, che consente la rimozione e il reprovisioning dei dispositivi sul campo nell'hub IoT senza modifiche al software del dispositivo.
L'esempio seguente illustra come implementare un flusso di lavoro di transizione da ambiente di test a ambiente di produzione tramite il servizio Device Provisioning.
Lo sviluppatore della soluzione collega sia i cloud IoT di test che di produzione al servizio di provisioning.
Il dispositivo implementa il protocollo DPS per trovare l'hub IoT, se non viene più effettuato il provisioning. Il provisioning del dispositivo viene inizialmente eseguito nell'ambiente di test.
Il dispositivo viene registrato nell'ambiente di test, quindi si connette e si verifica il test.
Lo sviluppatore esegui nuovamente il provisioning del dispositivo nell'ambiente di produzione e lo rimuove dall'hub di test. L'hub di test rifiuta il dispositivo alla successiva riconnessione.
Il dispositivo si connette e rinegozia il flusso di provisioning. Dps indirizza il dispositivo all'ambiente di produzione e il dispositivo si connette ed esegue l'autenticazione.
Per altre informazioni, vedere Panoramica del servizio Device Provisioning in hub IoT.
Collaboratori
Microsoft gestisce questo articolo. I collaboratori seguenti hanno scritto questo articolo.
Autori principali:
- Matthew Cosner | Principal Software Engineering Manager
- Ansley Yeo | Principal Program Manager
Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.