Tento článek obsahuje seznam položek, které byste měli zvážit při přesunu řešení IoT do produkčního prostředí.
Použití razítek nasazení
Kolky jsou samostatné jednotky základních komponent řešení, které podporují definovaný počet zařízení. Každá kopie se nazývá razítko. nebo jednotku škálování. Kolek se může například skládat ze sady základního souboru zařízení, ioT Hubu, centra událostí nebo jiného koncového bodu směrování a součásti pro zpracování. Každé razítko podporuje definovanou populaci zařízení. Zvolíte maximální počet zařízení, která může kolek obsahovat. S rostoucím počtem obyvatel zařízení přidáte instance kolků místo nezávislého vertikálního navýšení kapacity různých částí řešení.
Pokud místo přidávání razítek přesunete jednu instanci vašeho řešení IoT do produkčního prostředí, může dojít k následujícím omezením:
Omezení škálování: Jedna instance může narazit na limity š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: Komponenty řešení se nemusí škálovat lineárně s počtem provedených požadavků nebo objemem přijatých dat. U některých součástí může dojít ke snížení výkonu nebo zvýšení nákladů po splnění prahové hodnoty. Vertikální navýšení kapacity s větší kapacitou nemusí být tak dobrou strategií, jako je horizontální navýšení kapacity přidáním razítek.
Oddělení zákazníků: Možná budete muset zachovat data určitých zákazníků izolovaná od dat jiných zákazníků. Podobně můžete mít některé zákazníky, kteří k poskytování služeb vyžadují více systémových prostředků než jiné, a zvažte jejich seskupení na různých razítecích.
Instance s jedním a více tenanty: Můžete mít některé velké zákazníky, kteří potřebují 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 tenanty.
Složité požadavky na nasazení: Možná budete muset nasadit aktualizace do služby řízeným způsobem a nasadit je do různých kolků v různých časech.
Četnost aktualizací: Můžete mít některé zákazníky, kteří jsou odolní vůči časté aktualizaci vašeho systému, zatímco jiné můžou být rizikové a chtějí občasné aktualizace vaší služby.
Geografická nebo geopolitické omezení: Pokud chcete snížit latenci nebo splnit požadavky na suverenitu dat, můžete některé zákazníky nasadit do konkrétních oblastí.
Abyste předešli předchozím problémům, zvažte seskupení služby do několika razítek. Kolky fungují nezávisle na sobě a lze 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ě rozšířit kapacitu v rámci oblasti. Každé razítko obsahuje podmnožinu vašich zákazníků.
Použití zpětného vypnutí, když dojde k přechodné chybě
Všechny aplikace, které komunikují se vzdálenými službami a prostředky, musí být citlivé na přechodné chyby. To platí zejména pro aplikace, které běží v cloudu, kdy povaha prostředí a připojení přes internet znamená, že tyto typy chyb se pravděpodobně vyskytují častěji. Mezi přechodné chyby patří:
- Momentální ztráta síťového připojení ke komponentám a službám
- Dočasná nedostupnost služby
- Vypršení časových limitů, ke kterým dojde, když je služba zaneprázdněná
- Kolize způsobené souběžnou přenosem zařízení
Tyto chyby se často opravují sami a pokud se akce opakuje po vhodném zpoždění, pravděpodobně bude ú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í regrese. 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á, třeba kvůli události, jako je kolize síťových paketů nebo špička v hardwarové komponentě. 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ělo existovat více než jeden okamžitý pokus o opakování a měli byste přepnout na alternativní strategie, jako je exponenciální zpětné vypnutí nebo náhradní akce, pokud okamžité opakování selže.
- Randomizace. Každá z předchozích strategií opakování může obsahovat prvek randomizace, který zabrání více instancím klienta, které posílají následné pokusy o opakování ve stejnou dobu.
Vyhněte se také následujícím anti-vzorům:
- Implementace by neměly obsahovat 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.
- Nepoužívejte pravidelný interval 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í zřizování bezdotykového ovládání
Zřizování je registrace zařízení do Azure IoT Hubu. Zřizování zpřístupňuje Službu IoT Hub o zařízení a mechanismu ověření identity, který zařízení používá. Můžete použít službu Azure IoT Hub Device Provisioning Service (DPS) nebo zřídit přímo prostřednictvím rozhraní API správce registru služby IoT Hub. Použití DPS poskytuje výhodu pozdní vazby, což umožňuje odebrat a znovu zřazení polí zařízení do IoT Hubu beze změny softwaru zařízení.
Následující příklad ukazuje, jak implementovat pracovní postup přechodu testovacího prostředí do produkčního prostředí pomocí DPS.
- Vývojář řešení propojuje cloudy IoT pro testování a produkci se službou zřizování.
- Zařízení implementuje protokol DPS, aby našel IoT Hub, pokud už není zřízený. Zařízení je původně zřízeno pro testovací prostředí.
- Vzhledem k tomu, že je zařízení zaregistrované v testovacím prostředí, připojí se k němu a testování proběhne.
- Vývojář zařízení znovu zřídí do produkčního prostředí a odebere ho z testovacího centra. Testovací centrum odmítne zařízení při příštím připojení.
- Zařízení se připojí a znovu vyjedná tok zřizování. Služba DPS teď zařízení přesměruje do produkčního prostředí a zařízení se tam připojí a ověří.
Přispěvatelé
Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.
Hlavní autoři:
- Matthew Cosner | Hlavní správce softwarového inženýrství
- Ansley Yeo | Hlavní programový manažer
Pokud chcete zobrazit neveřejné profily LinkedIn, přihlaste se na LinkedIn.