Dit artikel bevat een lijst met items die u moet overwegen bij het verplaatsen van een IoT-oplossing naar een productieomgeving.
Implementatiestempels gebruiken
Stempels zijn discrete eenheden van kernoplossingsonderdelen die ondersteuning bieden voor een gedefinieerd aantal apparaten. Elke kopie wordt een stempel genoemd. of schaaleenheid. Een stempel kan bijvoorbeeld bestaan uit een set apparaatpopulatie, een IoT Hub, een Event Hub of een ander routeringseindpunt en een verwerkingsonderdeel. Elke stempel ondersteunt een gedefinieerde apparaatpopulatie. U kiest het maximum aantal apparaten dat de stempel kan bevatten. Naarmate de apparaatpopulatie groeit, voegt u stempelexemplaren toe in plaats van onafhankelijk verschillende onderdelen van de oplossing op te schalen.
Als u in plaats van stempels toe te voegen, één exemplaar van uw IoT-oplossing naar productie verplaatst, kunnen de volgende beperkingen optreden:
Schaallimieten: uw enkele instantie kan te maken krijgen met schaallimieten. Uw oplossing kan bijvoorbeeld gebruikmaken van services die beperkingen hebben voor het aantal binnenkomende verbindingen, hostnamen, TCP-sockets of andere resources.
Niet-lineair schalen of kosten: uw oplossingsonderdelen kunnen niet lineair worden geschaald met het aantal aanvragen of de hoeveelheid opgenomen gegevens. In plaats daarvan kunnen voor sommige onderdelen de prestaties afnemen of de kosten verhogen zodra aan een drempelwaarde is voldaan. Omhoog schalen met meer capaciteit is mogelijk niet zo goed als een strategie als uitschalen door stempels toe te voegen.
Scheiding van klanten: mogelijk moet u de gegevens van bepaalde klanten geïsoleerd houden van de gegevens van andere klanten. Op dezelfde manier hebt u mogelijk enkele klanten die meer systeemresources nodig hebben voor de service dan andere, en u kunt overwegen ze op verschillende stempels te groeperen.
Exemplaren van één en meerdere tenants: mogelijk hebt u enkele grote klanten die hun eigen onafhankelijke instanties van uw oplossing nodig hebben. Mogelijk hebt u ook een groep kleinere klanten die een implementatie met meerdere tenants kunnen delen.
Complexe implementatievereisten: Mogelijk moet u updates voor uw service op een gecontroleerde manier implementeren en op verschillende tijdstippen implementeren op verschillende stempels.
Updatefrequentie: U hebt mogelijk enkele klanten die tolerant zijn voor het hebben van frequente updates voor uw systeem, terwijl andere risico-averse zijn en onregelmatige updates voor uw service willen.
Geografische of geopolitieke beperkingen: als u de latentie wilt verminderen of aan de vereisten voor gegevenssoevereine wilt voldoen, kunt u enkele van uw klanten implementeren in specifieke regio's.
Als u de voorgaande problemen wilt voorkomen, kunt u overwegen om uw service in meerdere stempels te groeperen. Stempels werken onafhankelijk van elkaar en kunnen onafhankelijk worden geïmplementeerd en bijgewerkt. Eén geografische regio kan één stempel bevatten of meerdere stempels bevatten om horizontaal uitschalen binnen de regio mogelijk te maken. Elke stempel bevat een subset van uw klanten.
Back-off gebruiken wanneer er een tijdelijke fout optreedt
Alle toepassingen die met externe services en bronnen communiceren moeten gevoelig zijn voor tijdelijke fouten. Dit is met name het geval bij toepassingen die in de cloud worden uitgevoerd, waarbij de aard van de omgeving en connectiviteit via internet betekent dat deze typen fouten waarschijnlijk vaker voorkomen. Tijdelijke fouten zijn onder andere:
- Tijdelijk verlies van netwerkverbinding met onderdelen en services
- Tijdelijke niet-beschikbaarheid van een service
- Time-outs die optreden wanneer een service bezet is
- Botsingen veroorzaakt wanneer apparaten gelijktijdig verzenden
Deze fouten zijn vaak zelf corrigerend en als de actie wordt herhaald na een geschikte vertraging, slaagt dit waarschijnlijk. Het bepalen van de juiste intervallen tussen nieuwe pogingen is echter moeilijk. Typische strategieën gebruiken de volgende typen intervallen voor opnieuw proberen:
- Exponentieel uitstel. De toepassing wacht korte tijd voor de eerste poging wordt uitgevoerd. Vervolgens neemt het interval tussen de pogingen exponentieel toe. De nieuwe poging kan bijvoorbeeld na 3, 12, 30 seconden enzovoort worden uitgevoerd.
- Regelmatige intervallen. Het interval tussen pogingen is telkens even lang. De bewerken wordt bijvoorbeeld elke drie seconden herhaalt.
- Onmiddellijk opnieuw proberen. Soms is een tijdelijke fout kort, mogelijk vanwege een gebeurtenis zoals een netwerkpakketconflict of een piek in een hardwareonderdeel. In een dergelijk geval kan de bewerking het beste onmiddellijk opnieuw worden geprobeerd omdat deze kan slagen als de fout al is opgelost gedurende de tijd die het kost om de volgende aanvraag op te stellen en te verzenden. Er mag echter nooit meer dan één onmiddellijke nieuwe poging zijn en u moet overschakelen naar alternatieve strategieën, zoals exponentieel uitstel of terugvalacties, als de onmiddellijke nieuwe poging mislukt.
- Randomisatie. Een van de voorgaande strategieën voor opnieuw proberen kan een randomisatie-element bevatten om te voorkomen dat meerdere exemplaren van de client volgende nieuwe pogingen tegelijkertijd verzenden.
Vermijd ook de volgende antipatronen:
- Implementaties mogen geen dubbele lagen van code voor opnieuw proberen bevatten.
- Implementeer nooit een mechanisme waarbij eindeloos nieuwe pogingen worden uitgevoerd.
- Voer een onmiddellijke nieuwe poging nooit vaker dan eenmaal uit.
- Vermijd het gebruik van een regelmatig interval voor opnieuw proberen.
- Vermijd dat meerdere instanties van dezelfde client of meerdere instanties van verschillende clients tegelijkertijd nieuwe pogingen verzenden.
Zero Touch-inrichting gebruiken
Inrichten is het inschrijven van een apparaat bij Azure IoT Hub. Inrichten maakt IoT Hub op de hoogte van het apparaat en het attestation-mechanisme dat het apparaat gebruikt. U kunt de Azure IoT Hub Device Provisioning Service (DPS) gebruiken of rechtstreeks inrichten via IoT Hub Registry Manager-API's. Het gebruik van DPS biedt het voordeel van late binding, waardoor veldapparaten kunnen worden verwijderd en opnieuw in te richten op IoT Hub zonder de apparaatsoftware te wijzigen.
In het volgende voorbeeld ziet u hoe u een overgangswerkstroom voor test-naar-productieomgeving implementeert met behulp van DPS.
- De ontwikkelaar van de oplossing koppelt de IoT-clouds testen en productie aan de inrichtingsservice.
- Het apparaat implementeert het DPS-protocol om de IoT Hub te vinden, als het niet meer is ingericht. Het apparaat wordt in eerste instantie ingericht voor de testomgeving.
- Omdat het apparaat is geregistreerd bij de testomgeving, wordt er verbinding gemaakt en worden tests uitgevoerd.
- De ontwikkelaar richt het apparaat opnieuw in op de productieomgeving en verwijdert het uit de Test-hub. De testhub weigert het apparaat de volgende keer dat het opnieuw verbinding maakt.
- Het apparaat verbindt en onderhandelt opnieuw over de inrichtingsstroom. DPS stuurt het apparaat nu door naar de productieomgeving, waarna het apparaat daar verbinding maakt en verifieert.
Medewerkers
Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.
Belangrijkste auteurs:
- Matthew Cosner | Principal Software Engineering Manager
- Ansley Yeo | Principal Program Manager
Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.