IoT-megoldás áthelyezése tesztről élesre

Azure IoT Hub

Ez a cikk felsorolja azokat az elemeket, amelyeket érdemes figyelembe venni egy IoT-megoldás éles környezetbe való áthelyezésekor.

Üzembehelyezési bélyegek használata

A bélyegek az alapvető megoldás-összetevők különálló egységei, amelyek meghatározott számú eszközt támogatnak. Minden példányt bélyegnek nevezünk. vagy skálázási egység. A bélyegek például egy meghatározott eszközpopulációból, egy IoT Hubból, egy Eseményközpontból vagy más útválasztási végpontból és egy feldolgozási összetevőből állhatnak. Minden egyes bélyeg egy meghatározott eszközpopulációt támogat. Kiválaszthatja, hogy a bélyeg legfeljebb hány eszközt tartson meg. Az eszközpopuláció növekedésével a megoldás különböző részeinek egymástól független méretezése helyett bélyegpéldányokat adhat hozzá.

Ha a bélyegek hozzáadása helyett az IoT-megoldás egyetlen példányát helyezi át éles környezetbe, a következő korlátozások léphetnek fel:

  • Skálázási korlátok: Az önálló példány skálázási korlátokkal találkozhat. Előfordulhat például, hogy a megoldás olyan szolgáltatásokat használ, amelyek korlátozzák a bejövő kapcsolatok, gazdagépnevek, TCP-szoftvercsatornák vagy egyéb erőforrások számát.

  • Nem lineáris skálázás vagy költség: Előfordulhat, hogy a megoldás összetevői nem skálázhatók lineárisan a küldött kérelmek számával vagy a betöltött adatok mennyiségével. Egyes összetevők esetében azonban előfordulhat, hogy a küszöbérték teljesülése után csökken a teljesítmény vagy nő a költség. Előfordulhat, hogy a nagyobb kapacitással való vertikális felskálázás nem olyan jó stratégia, mint a bélyegek hozzáadásával történő horizontális felskálázás.

  • Ügyfelek elkülönítése: Előfordulhat, hogy bizonyos ügyfelek adatait el kell különíteni más ügyfelek adataitól. Hasonlóképpen előfordulhat, hogy egyes ügyfeleknek több rendszererőforrást kell kiszolgálnia, mint másoknak, és érdemes lehet különböző bélyegek szerint csoportosítani őket.

  • Egy- és több-bérlős példányok: Előfordulhat, hogy vannak olyan nagy ügyfelek, akiknek a megoldás saját független példányára van szükségük. Előfordulhat, hogy kisebb ügyfelek készlete is van, akik megoszthatnak több-bérlős üzembe helyezést.

  • Összetett üzembehelyezési követelmények: Előfordulhat, hogy a frissítéseket szabályozott módon kell üzembe helyeznie a szolgáltatásban, és különböző időpontokban kell üzembe helyeznie a különböző bélyegeken.

  • Frissítés gyakorisága: Előfordulhat, hogy vannak olyan ügyfelei, akik tolerálják a rendszer gyakori frissítéseit, míg mások kockázatkerülőek, és ritkán szeretnének frissítéseket kapni a szolgáltatáshoz.

  • Földrajzi vagy geopolitikai korlátozások: A késés csökkentése vagy az adatelkülönítési követelményeknek való megfelelés érdekében néhány ügyfelet üzembe helyezhet adott régiókban.

Az előző problémák elkerülése érdekében fontolja meg a szolgáltatás több bélyegbe való csoportosítását. A bélyegek egymástól függetlenül működnek, és egymástól függetlenül telepíthetők és frissíthetők. Egyetlen földrajzi régió egyetlen bélyeget tartalmazhat, vagy több bélyeget is tartalmazhat, hogy lehetővé tegye a horizontális felskálázást a régión belül. Minden egyes bélyeg az ügyfelek egy részhalmazát tartalmazza.

Visszakapcsolás használata átmeneti hiba esetén

A távoli szolgáltatásokkal és erőforrásokkal kommunikáló alkalmazásoknak érzékenynek kell lenniük az átmeneti hibákra. Ez különösen a felhőben futó alkalmazások esetében fordul elő, ahol a környezet jellege és az interneten keresztüli kapcsolat azt jelenti, hogy az ilyen típusú hibák valószínűleg gyakrabban fordulnak elő. Átmeneti hibák a következők:

  • Az összetevők és szolgáltatások hálózati kapcsolatának pillanatnyi megszakadása
  • Szolgáltatás ideiglenes elérhetetlensége
  • A szolgáltatás foglaltsága esetén felmerülő időtúllépések
  • Ütközések, amelyek akkor keletkeznek, ha az eszközök egyidejűleg továbbítják

Ezek a hibák gyakran önjavítóak, és ha a művelet megfelelő késleltetés után ismétlődik, valószínűleg sikeres lesz. Az újrapróbálkozások közötti megfelelő időközök meghatározása azonban nehéz. A tipikus stratégiák az alábbi típusú újrapróbálkozási időközöket használják:

  • Exponenciális visszatartás. Az alkalmazás rövid ideig várakozik az első újrapróbálkozás előtt, majd exponenciálisan növeli a próbálkozások közötti időt. Például megpróbálhatja újra végrehajtani a műveletet 3 másodperc, 12 másodperc, 30 másodperc múlva és így tovább.
  • Rendszeres időközök. Az alkalmazás ugyanannyi ideig várakozik a próbálkozások között. Például megpróbálhatja újra végrehajtani a műveletet 3 másodpercenként.
  • Azonnali újrapróbálkozás. Előfordulhat, hogy egy átmeneti hiba rövid, például egy hálózati csomag ütközése vagy egy hardverösszetevő csúcsa miatt. Ebben az esetben célszerű azonnal megismételni a műveletet, mivel az sikerrel járhat, ha a hiba még az idő alatt megszűnik, hogy az alkalmazás összeállítja és elküldi a következő kérést. Az azonnali újrapróbálkozási kísérletnél azonban soha ne legyen több, és váltson alternatív stratégiákra, például exponenciális visszalépési vagy tartalék műveletekre, ha az azonnali újrapróbálkozás meghiúsul.
  • Véletlenszerűsítés. Az előző újrapróbálkozási stratégiák bármelyike tartalmazhat véletlenszerűsítési elemet, amely megakadályozza, hogy az ügyfél több példánya egyidejűleg küldjön további újrapróbálkozási kísérleteket.

Kerülje a következő antimintákat is:

  • A megvalósítások nem tartalmazhatnak ismétlődő újrapróbálkozási kódrétegeket.
  • Soha ne implementáljon végtelen újrapróbálkozási mechanizmust.
  • Soha ne végezzen azonnali újrapróbálkozást egynél több alkalommal.
  • Kerülje a rendszeres újrapróbálkozási időköz használatát.
  • Akadályozza meg, hogy egy adott ügyfél több példánya, vagy különböző ügyfelek több példánya egyszerre küldjön újrapróbálkozásokat.

Érintés nélküli üzembe helyezés használata

A kiépítés az eszköz Azure IoT Hubba való regisztrálásának művelete. A kiépítés révén az IoT Hub tudomást szerez az eszközről és az eszköz által használt igazolási mechanizmusról. Használhatja az Azure IoT Hub Device Provisioning Service-t (DPS), vagy közvetlenül az IoT Hub Registry Manager API-kkal építhet ki. A DPS használata biztosítja a késői kötés előnyeit, amely lehetővé teszi a mezőeszközök IoT Hubra való eltávolítását és újbóli üzembe helyezését az eszközszoftver módosítása nélkül.

Az alábbi példa bemutatja, hogyan implementálhat egy teszt-éles környezet közötti átállási munkafolyamatot a DPS használatával.

Egy diagram, amely bemutatja, hogyan implementálhat egy tesztkörnyezet közötti átállási munkafolyamatot a DPS használatával.

  1. A megoldásfejlesztő összekapcsolja a tesztelési és éles IoT-felhőket a kiépítési szolgáltatással.
  2. Az eszköz a DPS protokollt implementálja az IoT Hub megkereséséhez, ha már nincs kiépítve. Az eszköz kezdetben ki van építve a tesztkörnyezetben.
  3. Mivel az eszköz regisztrálva van a tesztkörnyezetben, ott csatlakozik, és tesztelés történik.
  4. A fejlesztő újra kiépíti az eszközt az éles környezetbe, és eltávolítja azt a Tesztközpontból. A Tesztközpont a legközelebbi újracsatlakozáskor elutasítja az eszközt.
  5. Az eszköz csatlakozik, és újra egyezteti a kiépítési folyamatot. A DPS mostantól az éles környezetbe irányítja az eszközt, és az eszköz ott csatlakozik és hitelesít.

Közreműködők

Ezt a cikket a Microsoft tartja karban. Eredetileg a következő közreműködők írták.

Fő szerzők:

A nem nyilvános LinkedIn-profilok megtekintéséhez jelentkezzen be a LinkedInbe.

Következő lépések