Přesunutí řešení IoT z testu do produkčního prostředí
Tento článek obsahuje seznam položek, které byste měli vzít v úvahu při přesunu řešení IoT do provozního prostředí.
Použít razítka nasazení
Razítka jsou diskrétní jednotky základních komponent řešení, které podporují definovaný počet zařízení. Každá kopie se nazývá razítko. nebo jednotka škálování. Razítko se může skládat například ze sady naplněných zařízení, IoT Hub, centra událostí nebo jiného koncového bodu směrování a komponenty pro zpracování. Každé razítko podporuje definované naplnění zařízení. Zvolíte maximální počet zařízení, která razítko může uchovávat. Jakmile se naplní zařízení, místo nezávislého škálování různých částí řešení se přidávají instance razítek.
Pokud místo přidávání razítek přidáte razítka, přesunete jednu instanci řešení IoT do produkčního prostředí, může dojít k následujícím omezením:
Omezení škálování: Vaše jediná instance může narazit na omezení škálování. Vaše řešení může například používat služby, které mají omezení počtu příchozích připojení, názvů hostitelů, soketů TCP nebo jiných prostředků.
Nelineární škálování nebo náklady: Vaše součásti řešení se nemusí lineárně škálovat s využitím počtu zpracovaných požadavků nebo množství dat, která se ingestují. Místo toho se u některých komponent může snížit výkon nebo zvýšit náklady, jakmile se splní prahová hodnota. Škálování s větší kapacitou nemusí být jako dobrá strategie pro horizontální navýšení kapacity přidáním razítek.
Oddělení zákazníků: Možná budete muset uchovávat data některých zákazníků izolovaná od ostatních zákaznických dat. Podobně můžete mít nějaké zákazníky, kteří vyžadují více systémových prostředků pro službu než jiné, a zvažte seskupení těchto prostředků na různá razítka.
Jedna a více tenantů – instance: Je možné, že máte několik velkých zákazníků, kteří potřebují své vlastní nezávislé instance vašeho řešení. Můžete mít také fond menších zákazníků, kteří můžou sdílet nasazení s více klienty.
Komplexní požadavky na nasazení: Je možné, že bude nutné nasazovat aktualizace vaší služby a nasazovat je na různá razítka v různou dobu.
Frekvence aktualizace: Můžou mít někteří zákazníci, kteří mají v systému k dispozici časté aktualizace, zatímco jiné můžou být rizikové – Averse a chtějí mít k dispozici zřídka aktualizované služby.
Zeměpisná nebo geopolitická omezení: Pokud chcete snížit latenci nebo dodržovat požadavky na suverenitu dat, můžete do konkrétních oblastí nasadit některé z vašich zákazníků.
Abyste předešli předchozím problémům, zvažte seskupení služby do několika razítek. Razítka fungují nezávisle na sobě a je možné je nasadit a aktualizovat nezávisle. Jedna geografická oblast může obsahovat jedno razítko nebo může obsahovat více razítek, aby bylo možné horizontální horizontální navýšení kapacity v rámci oblasti. Každé razítko obsahuje podmnožinu vašich zákazníků.
Pokud dojde k přechodné chybě, použijte Back-off.
Všechny aplikace, které komunikují se vzdálenými službami a prostředky, musí být citlivé na přechodné chyby. To je obzvláště v případě aplikací, které běží v cloudu, kde povaha prostředí a připojení přes Internet znamená, že tyto typy chyb budou pravděpodobně často zjištěny. Přechodné chyby zahrnují:
- Okamžiková ztráta síťového připojení k součástem a službám
- Dočasná nedostupnost služby
- Vypršení časových limitů, které vznikají při zaneprázdněnosti služby
- Kolizí způsobená souběžným přenosem zařízení
Tyto chyby se často nahrazují automatickým opravou a pokud se akce opakuje po přiměřené prodlevě, bude nejspíš úspěšná. Určení vhodných intervalů mezi opakovanými pokusy je však obtížné. Typické strategie používají následující typy intervalů opakování:
- Exponenciální zpět. Aplikace čeká po krátkou dobu před prvním opakováním a pak exponenciálně prodlužuje časy mezi každým dalším pokusem. Může například operaci opakovat za 3 sekundy, 12 sekund, 30 sekund a tak dále.
- Pravidelné intervaly. Aplikace čeká mezi jednotlivými pokusy stejnou dobu. Například může operaci opakovat každé 3 sekundy.
- Okamžité opakování. Někdy je přechodná chyba krátká, možná kvůli události, jako je například kolizí síťových paketů nebo špička v hardwarové součásti. V takovém případě je vhodné zkusit operaci znovu okamžitě, protože může být úspěšná, když došlo k vyřešení situace v době, kterou aplikaci trvá sestavit a odeslat další požadavek. Nikdy by však neměl být více než jeden okamžitý pokus o opakování a v případě, že se okamžité opakování nezdaří, byste měli přepnout na alternativní strategie, jako je exponenciální záložní nebo záložní akce.
- Náhodnost. Kterákoli z výše uvedených strategií opakování může zahrnovat prvek náhodnosti, aby se zabránilo více instancím klienta odesílat následné pokusy o opakování ve stejnou dobu.
Vyhněte se také následujícím antipatternům:
- Implementace by neměly zahrnovat duplicitní vrstvy kódu opakování.
- Nikdy implementujte mechanismus s nekonečným počtem opakování.
- Nikdy neprovádějte okamžité opakování víc než jednou.
- Vyhněte se použití pravidelného intervalu opakování.
- Zabraňte více instancím stejného klienta nebo více instancím různých klientů v odesílání pokusů o opakování ve stejnou dobu.
Použití nulového zřizování
Zřizování je postup registrace zařízení do služby Azure IoT Hub. Zřizování zajišťuje IoT Hub vědomi zařízení a mechanismu ověřování, které zařízení používá. Můžete použít Azure IoT Hub Device Provisioning Service (DPS) nebo zřídit přímo prostřednictvím rozhraní API IoT Hub Správce registru. Použití DPS přinese výhody pozdní vazby, která umožňuje odebrání a opětovné zřízení zařízení s poli, aby IoT Hub beze změny softwaru zařízení.
Následující příklad ukazuje, jak implementovat pracovní postup přechodu z testovacího prostředí do produkčního prostředí pomocí DPS.
- Vývojář řešení propojuje testovací a produkční cloudy IoT se službou zřizování.
- Zařízení implementuje protokol DPS, aby našli IoT Hub, pokud už není zřízené. Zařízení se zpočátku zřídí do testovacího prostředí.
- Vzhledem k tomu, že je zařízení zaregistrované v testovacím prostředí, dojde k jeho připojení a testování.
- Vývojář znovu zřídí zařízení do provozního prostředí a odebere ho z centra testů. Centrum testů odmítne zařízení při příštím opětovném připojení.
- Zařízení se připojí a znovu domlouvá tok zřizování. DPS nyní přesměruje zařízení do provozního prostředí a zařízení tam připojí a ověří.