Flytta en IoT-lösning från test till produktion
Den här artikeln innehåller en lista över objekt som du bör tänka på när du flyttar en IoT-lösning till en produktionsmiljö.
Använda distributionsstämplar
Stämplar är diskreta enheter med kärnlösningskomponenter som stöder ett definierat antal enheter. Varje kopia kallas för en stämpel. eller skalningsenhet. En stämpel kan till exempel bestå av en uppsättning enhetspopulation, en IoT Hub, en händelsehubb eller en annan routningsslutpunkt och en bearbetningskomponent. Varje stämpel stöder en definierad enhetspopulation. Du väljer det maximala antalet enheter som stämpeln kan innehålla. När enhetspopulationen växer lägger du till stämpelinstanser i stället för att skala upp olika delar av lösningen oberoende av varandra.
Om du flyttar en enskild instans av din IoT-lösning till produktion i stället för att lägga till stämplar kan du stöta på följande begränsningar:
Skalningsgränser: Din enskilda instans kan stöta på skalningsgränser. Lösningen kan till exempel använda tjänster som har begränsningar för antalet inkommande anslutningar, värdnamn, TCP-sockets eller andra resurser.
Icke-linjär skalning eller kostnad: Lösningskomponenterna kan inte skalas linjärt med antalet begäranden som görs eller mängden data som matas in. För vissa komponenter kan det i stället ske en minskning i prestanda eller ökning av kostnaden när ett tröskelvärde har uppnåtts. Att skala upp med mer kapacitet kanske inte är en lika bra strategi som att skala ut genom att lägga till stämplar.
Uppdelning av kunder: Du kan behöva hålla vissa kunders data isolerade från andra kunders data. På samma sätt kan du ha vissa kunder som behöver fler systemresurser för tjänsten än andra och överväga att gruppera dem på olika stämplar.
Instanser med en enda klientorganisation och flera klienter: Du kan ha några stora kunder som behöver sina egna oberoende instanser av din lösning. Du kan också ha en pool med mindre kunder som kan dela en distribution med flera innehavare.
Komplexa distributionskrav: Du kan behöva distribuera uppdateringar till din tjänst på ett kontrollerat sätt och distribuera till olika stämplar vid olika tidpunkter.
Uppdateringsfrekvens: Du kan ha vissa kunder som är toleranta för att ha frekventa uppdateringar av systemet, medan andra kan vara riskaverser och vill ha ovanliga uppdateringar av din tjänst.
Geografiska eller geopolitiska begränsningar: Om du vill minska svarstiden eller uppfylla kraven på datasuveränitet kan du distribuera några av dina kunder till specifika regioner.
Överväg att gruppera tjänsten i flera stämplar för att undvika föregående problem. Stämplar fungerar oberoende av varandra och kan distribueras och uppdateras oberoende av varandra. En enda geografisk region kan innehålla en enda stämpel eller innehålla flera stämplar för horisontell utskalning i regionen. Varje stämpel innehåller en delmängd av dina kunder.
Använd back-off när ett tillfälligt fel inträffar
Alla program som kommunicerar med fjärrtjänster och -resurser måste vara känsliga för tillfälliga fel. Detta gäller särskilt för program som körs i molnet, där typen av miljö och anslutning via Internet innebär att dessa typer av fel troligen förekommer oftare. Tillfälliga fel är:
- Momentary loss of network connectivity to components and services (Direkt förlust av nätverksanslutning till komponenter och tjänster)
- Tillfällig otillgänglighet för en tjänst
- Tidsgränser som uppstår när en tjänst är upptagen
- Kollisioner som orsakas när enheter överför samtidigt
Dessa fel är ofta själv korrigerande, och om åtgärden upprepas efter en lämplig fördröjning är det troligt att den lyckas. Det är dock svårt att fastställa lämpliga intervall mellan återförsök. Vanliga strategier använder följande typer av återförsöksintervall:
- Exponentiell back-off. Programmet väntar en kort tid innan det första återförsöket och ökar sedan exponentiellt tiden mellan varje efterföljande återförsök. Det kan t.ex. göra ett återförsök efter 3 sekunder, 12 sekunder, 30 sekunder och så vidare.
- Regelbundna intervall. Programmet väntar samma tid mellan varje återförsök. Det kan till exempel göra ett återförsök för åtgärden var tredje sekund.
- Omedelbart återförsök. Ibland är ett tillfälligt fel kort, kanske på grund av en händelse, till exempel en kollision mellan nätverkspaket eller en topp i en maskinvarukomponent. I det här fallet är det lämpligt att omedelbart göra ett återförsök eftersom det kan lyckas om felet har åtgärdats under tiden det tar för programmet att sätta samman och skicka nästa begäran. Det bör dock aldrig finnas fler än ett omedelbart återförsök och du bör växla till alternativa strategier, till exempel exponentiella back off- eller återställningsåtgärder, om det omedelbara återförsöket misslyckas.
- Randomisering. Alla föregående återförsöksstrategier kan innehålla ett randomiseringselement för att förhindra att flera instanser av klienten skickar efterföljande återförsök samtidigt.
Undvik även följande antimönster:
- Implementeringar bör inte innehålla duplicerade lager med återförsökskod.
- Implementera aldrig en oändlig mekanism för återförsök.
- Utför aldrig ett omedelbart återförsök mer än en gång.
- Undvik att använda ett regelbundet återförsöksintervall.
- Förhindra att flera instanser av samma klient, eller flera instanser av olika klienter, skickar återförsök vid samma tidpunkt.
Använda zero-touch-etablering
Etablering handlar om att registrera en enhet i Azure IoT Hub. Etableringen gör IoT Hub medveten om enheten och attestationsmekanismen som enheten använder. Du kan använda Azure IoT Hub Device Provisioning Service (DPS) eller etablera direkt via IoT Hub Registry Manager-API:er. Användning av DPS berättigar fördelen med sen bindning, vilket gör det möjligt att ta bort och ometablera fältenheter för att IoT Hub utan att ändra enhetens programvara.
I följande exempel visas hur du implementerar ett arbetsflöde för övergången från test till produktionsmiljö med hjälp av DPS.
- Lösningsutvecklaren länkar test- och produktionsmoln för IoT till etableringstjänsten.
- Enheten implementerar DPS-protokollet för att hitta IoT Hub om det inte längre är etablerat. Enheten etableras först i testmiljön.
- Eftersom enheten är registrerad i testmiljön ansluts den där och testningen sker.
- Utvecklaren återetterar enheten till produktionsmiljön och tar bort den från testhubben. Testhubben avvisar enheten nästa gång den återansluts.
- Enheten ansluter och förhandlar om etableringsflödet. DPS dirigerar nu enheten till produktionsmiljön och enheten ansluter och autentiserar där.