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 separat skala upp olika delar av lösningen.
Om du i stället för att lägga till stämplar flyttar en enda instans av din IoT-lösning till produktion kan följande begränsningar uppstå:
Skalningsgränser: Din enda instans kan stöta på skalningsgränser. Din lösning kan till exempel använda tjänster som har gränser för antalet inkommande anslutningar, värdnamn, TCP-socketar eller andra resurser.
Icke-linjär skalning eller kostnad: Lösningskomponenterna kanske 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 uppstå en minskning av prestanda eller ökade kostnader 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.
Separation 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 mer systemresurser för att betjäna än andra och överväga att gruppera dem på olika stämplar.
Enskilda instanser och instanser med flera klientorganisationer: 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 klientorganisationer.
Komplexa distributionskrav: Du kan behöva distribuera uppdateringar till tjänsten på ett kontrollerat sätt och distribuera till olika stämplar vid olika tidpunkter.
Uppdateringsfrekvens: Du kan ha vissa kunder som är toleranta mot att ha frekventa uppdateringar av systemet, medan andra kan vara riskvilliga 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.
Om du vill undvika föregående problem bör du överväga att gruppera tjänsten i flera stämplar. Stämplar fungerar oberoende av varandra och kan distribueras och uppdateras separat. En enda geografisk region kan innehålla en enda stämpel eller innehålla flera stämplar för horisontell utskalning inom 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 miljöns natur och anslutningen via Internet innebär att dessa typer av fel sannolikt kommer att uppstå oftare. Tillfälliga fel omfattar:
- Tillfällig 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örs samtidigt
Dessa fel är ofta självkorrigeringar, och om åtgärden upprepas efter en lämplig fördröjning kommer den sannolikt att 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 backoff. 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 med 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 göras fler än ett omedelbart återförsök, och du bör växla till alternativa strategier, till exempel exponentiell säkerhetskopiering eller återställningsåtgärder, om det omedelbara återförsöket misslyckas.
- Slumpmässighet. Någon av de föregående återförsöksstrategierna kan innehålla ett slumpmässigt element 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 av å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. Etablering gör IoT Hub medveten om enheten och attesteringsmekanismen som enheten använder. Du kan använda Azure IoT Hub Device Provisioning Service (DPS) eller etablera direkt via API:er för IoT Hub Registry Manager. Att använda DPS ger fördelen med sen bindning, vilket gör det möjligt att ta bort och återskapa fältenheter till IoT Hub utan att ändra enhetsprogramvaran.
I följande exempel visas hur du implementerar ett arbetsflöde för test-till-produktionsmiljöövergång med hjälp av DPS.
- Lösningsutvecklaren länkar test- och produktions-IoT-molnen till etableringstjänsten.
- Enheten implementerar DPS-protokollet för att hitta IoT Hub, om den inte längre är etablerad. Enheten etableras ursprungligen i testmiljön.
- Eftersom enheten är registrerad i testmiljön ansluter den där och testning sker.
- Utvecklaren etablerar om 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.
Deltagare
Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.
Huvudsakliga författare:
- Matthew Cosner | Principal Software Engineering Manager
- Ansley Yeo | Programhanteraren för huvudnamn
Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.