Uwaga
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
W tym artykule opisano kilka często używanych metod rozwiązywania problemów z wieloma dzierżawami dla rozwiązań opartych na usłudze Azure IoT Hub. Wielotenanckie rozwiązania oparte na usłudze IoT Hub są dostępne w wielu różnych wersjach i rozmiarach. Może istnieć wiele wymagań i ograniczeń, od własności infrastruktury, po izolację danych klientów po zgodność. Może to być trudne do zdefiniowania wzorca spełniającego wszystkie te ograniczenia projektowe i często wymaga rozważenia wielu wymiarów.
Kluczowe zagadnienia i wymagania
Te zagadnienia i wymagania są prezentowane w kolejności, w jakiej są one zwykle priorytetowe dla projektu rozwiązania.
Zarządzanie i zgodność
Zagadnienia dotyczące ładu i zgodności mogą wymagać użycia określonego wzorca lub zestawu zasobów IoT. Nie wszystkie usługi IoT mają te same certyfikaty lub możliwości. Jeśli musisz spełnić określone standardy zgodności, może być konieczne wybranie określonych usług. Aby dowiedzieć się więcej, zobacz Podejścia architektoniczne do zarządzania i zgodności w wielodostępnych rozwiązaniach.
Zarządzanie w usłudze IoT może również mieć inne formy, takie jak własność urządzeń i zarządzanie nimi. Czy klient jest właścicielem urządzenia, czy dostawcą rozwiązań? Kto jest właścicielem zarządzania tymi urządzeniami? Te zagadnienia i implikacje są unikatowe dla każdego dostawcy rozwiązań i mogą prowadzić do różnych wyborów w zakresie technologii, wzorca wdrażania i wzorca wielodostępności, którego używasz.
Skala
Ważne jest zaplanowanie skali rozwiązania. Skalowanie jest często brane pod uwagę w tych trzech wymiarach:
Ilość urządzeń: wszystkie usługi zarządzania urządzeniami platformy Azure — Azure IoT Central, Azure IoT Hub Device Provisioning Service (DPS) i Azure IoT Hub — mają ograniczenia dotyczące liczby urządzeń obsługiwanych w jednym wystąpieniu.
Napiwek
Jeśli planujesz wdrożyć bardzo dużą liczbę urządzeń, zapoznaj się z dokumentacją o dużej skali.
Przepływność urządzenia: różne urządzenia, nawet w tym samym rozwiązaniu, mogą mieć różne wymagania dotyczące przepływności. "Przepływność" w tym kontekście odnosi się zarówno do liczby komunikatów w danym okresie, jak i do rozmiaru komunikatów. Na przykład w:
- Rozwiązanie dla inteligentnych budynków, termostaty zwykle zgłaszają dane o niższej częstotliwości niż windy.
- W rozwiązaniu połączonym pojazdem komunikaty dotyczące rejestrowania danych z kamery pojazdów są zwykle większe niż komunikaty telemetryczne nawigacji.
Jeśli komunikaty są ograniczane pod względem częstotliwości, rozważ zwiększenie liczby instancji usługi. Jeśli rozmiar wiadomości jest ograniczany, rozważ zwiększenie instancji usługi do większych.
Najemcy: Skala pojedynczego najemcy może być mała, ale pomnożona przez liczbę najemców, może szybko rosnąć.
Wydajność i niezawodność
Izolacja najemców
W pełni udostępnione rozwiązania mogą mieć hałaśliwych sąsiadów. W przypadku usług IoT Hub i IoT Central sąsiedzi hałaśliwi mogą spowodować kod odpowiedzi HTTP 429 ("Zbyt wiele żądań"), które są twardymi błędami, które mogą powodować efekt kaskadowy. Aby uzyskać więcej informacji, zobacz Limity przydziału i ograniczanie przepustowości.
W w pełni wielodostępnych rozwiązaniach te efekty mogą być kaskadowe. Gdy klienci udostępniają aplikacje usługi IoT Hub lub IoT Central, wszyscy klienci w udostępnionej infrastrukturze otrzymują błędy. Ponieważ usługi IoT Hub i IoT Central są często punktami wejścia dla danych w chmurze, inne systemy podrzędne, które zależą od tych danych, również mogą zakończyć się niepowodzeniem. Często najczęstszą przyczyną tych błędów jest przekroczenie limitu przydziału komunikatów. W takiej sytuacji najszybszą i najprostszą poprawką dla rozwiązań usługi IoT Hub jest uaktualnienie jednostki SKU usługi IoT Hub, zwiększenie liczby jednostek usługi IoT Hub lub obu tych rozwiązań. W przypadku rozwiązań usługi IoT Central rozwiązanie jest automatycznie skalowane w razie potrzeby do udokumentowanej liczby obsługiwanych komunikatów.
Możesz izolować i dystrybuować dzierżawców na płaszczyznach kontroli, zarządzania i komunikacji IoT, korzystając z niestandardowych zasad alokacjiusług DPS
Magazyn danych, zapytania, użycie i przechowywanie danych
Rozwiązania IoT zwykle intensywnie korzystają z danych, zarówno podczas przesyłania strumieniowego, jak i w stanie spoczynku. Aby uzyskać więcej informacji na temat zarządzania danymi w rozwiązaniach wielodostępnych, zobacz Metody architektury magazynowania i danych w rozwiązaniach wielodostępnych.
Zabezpieczenia
Rozwiązania IoT często mają zagadnienia dotyczące zabezpieczeń na wielu warstwach, zwłaszcza w rozwiązaniach, które są wdrażane w zmodyfikowanej przez chmurę architekturze referencyjnej przedsiębiorstwa Purdue lub rozwiązaniach Przemysłu 4.0. Wybrane podejście projektowe ma wpływ na istniejące warstwy i granice sieci; po wybraniu projektu fizycznego możesz wybrać implementację zabezpieczeń. W dowolnej metodzie można użyć następujących narzędzi:
Microsoft Defender for IoT, kompleksowe rozwiązanie do monitorowania IoT, które warto rozważyć. Oferuje licencję EIoT na urządzenie oraz licencje na witryny OT dla każdego urządzenia klienta i/lub witryny. W zależności od podejścia wybranego w dalszej części tego artykułu scenariusz licencjonowania użytkowników o nazwie Microsoft 365 może nie być możliwy. W takim przypadku dostępne są opcje licencji na urządzenie i witrynę, które są opcjami licencji niezależnie od licencji dzierżawy platformy Microsoft 365.
usługę Azure Firewall lub urządzenie zapory firmy innej niż Microsoft, które należy wziąć pod uwagę pod kątem izolowania warstw sieciowych i monitorowania ruchu sieciowego. Dokładny wybór podejścia określa, czy obciążenia mają izolację sieci, czy są w sieci udostępnionej, co zostanie omówione później w tym artykule.
Większość z tych tematów dotyczących zabezpieczeń ma zastosowanie w rozwiązaniu wielodostępnym podobnie jak w rozwiązaniu jednolokatorskim, z różnicami związanymi z wybranym podejściem. Jednym składnikiem, który prawdopodobnie będzie znacznie inny w ogólnym rozwiązaniu IoT, jest tożsamość użytkownika i aplikacji. Podejścia architektoniczne do zarządzania tożsamością w rozwiązaniach multitenantowych omawiają ten aspekt ogólnego rozwiązania multitenantowego.
Podejścia do rozważenia
Zagadnienia i wybory dotyczące podstawowych składników, takich jak zarządzanie, pozyskiwanie, przetwarzanie, przechowywanie i zabezpieczenia, są takie same w przypadku rozwiązań IoT jednokrotnych i wielonajemnych. Podstawową różnicą jest sposób rozmieszczania i wykorzystywania składników do obsługi wielodostępności. Na przykład typowe punkty decyzyjne dla:
- Przechowywanie danych może obejmować wybór korzystania z aplikacji SQL Server lub Azure Data Explorer.
- Warstwa pozyskiwania i zarządzania polega na wybraniu między usługą IoT Hub i usługą IoT Central.
Większość rozwiązań IoT mieści się w głównym wzorcu architektury, który jest kombinacją docelowego wdrożenia, modelu dzierżawy i wzorca wdrażania. Kluczowe wymagania i zagadnienia opisane wcześniej określają te czynniki.
Jednym z największych punktów decyzyjnych, które należy podjąć, w przestrzeni IoT, jest wybranie między podejściami typu "platforma jako usługa" (aPaaS) i "platforma jako usługa" (PaaS). Aby dowiedzieć się więcej, zobacz Porównanie podejść do rozwiązań Internetu Rzeczy (IoT) (PaaS vs aPaaS).
Ten wybór jest typowym dylematem „budować czy kupować”, z którym boryka się wiele organizacji w różnych projektach. Ważne jest, aby ocenić zalety i wady obu opcji.
Pojęcia i zagadnienia dotyczące rozwiązań aPaaS
Typowe rozwiązanie aPaaS korzystające z usługi Azure IoT Central jako podstawowe rozwiązanie może używać następujących usług PaaS i aPaaS:
- Usługa Azure Event Hubs jako wieloplatformowy, klasy korporacyjnej silnik komunikatów i przepływu danych.
- Usługa Azure Logic Apps jako platforma integracji jako usługa lub oferta iPaaS.
- Usługa Azure Data Explorer jako platforma analizy danych.
- Usługa Power BI jako platforma wizualizacji i raportowania.
Diagram architektury współdzierżawców opartej na IoT Hub, pokazujący dzierżawców współdzielących środowisko IoT Central, Eksplorator danych, Power BI i Logic Apps.
Na poprzednim diagramie dzierżawcy współdzielą środowisko IoT Central, Azure Data Explorer, Power BI oraz Azure Logic Apps.
Takie podejście jest zazwyczaj najszybszym sposobem uzyskania rozwiązania na rynek. Jest to usługa o dużej skali, która obsługuje multitenancy za pomocą organizacji.
Ważne jest, aby zrozumieć, że ponieważ usługa IoT Central jest ofertą aPaaS, istnieją pewne decyzje, które są poza kontrolą implementatora. Te decyzje obejmują:
- Usługa IoT Central używa identyfikatora Entra firmy Microsoft jako dostawcy tożsamości.
- Wdrożenia usługi IoT Central są realizowane przy użyciu operacji sterowania i płaszczyzny danych, które łączą dokumenty deklaratywne z kodem imperatywnym.
- Maksymalna liczba węzłów i maksymalna głębokość drzewa w wielodostępnym wzorcu opartym na usłudze IoT Central mogą zmusić dostawcę usług do posiadania wielu wystąpień usługi IoT Central. W takim przypadku należy rozważyć zastosowanie wzorca pieczęci wdrożeniowej.
- Usługa IoT Central nakłada limity wywołań interfejsu API , co może mieć wpływ na duże implementacje.
Pojęcia i zagadnienia dotyczące rozwiązań PaaS
Podejście oparte na modelu PaaS może korzystać z następujących usług platformy Azure:
- Usługa Azure IoT Hub jako podstawowa platforma konfiguracji i komunikacji urządzeń.
- Usługa Azure IoT Device Provisioning Service jako platforma wdrażania urządzenia i początkowej konfiguracji.
- Usługa Azure Data Explorer do przechowywania i analizowania danych szeregów czasowych ścieżki ciepłej i zimnej z urządzeń IoT.
- Usługa Azure Stream Analytics do analizowania danych ścieżek gorących z urządzeń IoT.
- Azure IoT Edge do uruchamiania sztucznej inteligencji (AI), usług innych niż Microsoft lub własnej logiki biznesowej na urządzeniach IoT Edge.
Na poprzednim diagramie każdy najemca łączy się ze współdzieloną aplikacją webową, która odbiera dane z IoT Hubs oraz aplikacji funkcji. Urządzenia łączą się z usługą Device Provisioning Service i z usługą IoT Hubs.
Takie podejście wymaga większego nakładu pracy dewelopera w celu utworzenia, wdrożenia i utrzymania rozwiązania (w porównaniu z podejściem aPaaS). Mniejsza liczba możliwości jest wstępnie skompilowana dla wygody implementatora. W związku z tym takie podejście zapewnia również większą kontrolę, ponieważ mniej założeń jest osadzonych na platformie bazowej.
Wzorce architektury głównej
W poniższej tabeli wymieniono typowe wzorce dla wielodostępnych rozwiązań IoT. Każdy wzorzec zawiera następujące informacje:
- Nazwa wzorca, który jest oparty na kombinacji celu, modelu i typu wdrożenia.
- Cel wdrożenia reprezentujący subskrypcję platformy Azure, do której wdrażane są zasoby.
- Model najmu, do którego odnosi się wzorzec, zgodnie z opisem w temacie Modele wielodostępności
- Wzorzec wdrożeniowy, odwołujący się do prostego wdrożenia z minimalnymi zagadnieniami dotyczącymi wdrażania, wzorzec geody lub wzorzec pieczątki wdrożeniowej.
Wzorzec | Cel wdrożenia | Model dzierżawy | Wzorzec wdrażania |
---|---|---|---|
Proste SaaS | Subskrypcja dostawcy usług | W pełni wielodostępny | Uproszczony |
Horyzontalny SaaS | Subskrypcja dostawcy usług | Podział poziomy | Sygnatura wdrożenia |
Automatyzacja dla pojedynczego dzierżawcy | Subskrypcja dostawcy usług lub klienta | Jeden najemca na klienta | Uproszczony |
Proste SaaS
Cel wdrożenia | Model dzierżawy | Wzorzec wdrożenia |
---|---|---|
Subskrypcja dostawcy usług | W pełni wielodostępny | Uproszczony |
Proste podejście SaaS to najprostsza implementacja rozwiązania SaaS IoT. Jak pokazano na poprzednim diagramie, wszystkie infrastruktury są współużytkowane, a infrastruktura nie ma zastosowanych sygnatur geograficznych ani skalowania. Często infrastruktura znajduje się w ramach jednej subskrypcji platformy Azure.
Usługa Azure IoT Central obsługuje koncepcję organizacji. Organizacje umożliwiają dostawcy rozwiązań łatwe segregowanie dzierżaw w bezpieczny, hierarchiczny sposób, a jednocześnie udostępnianie podstawowego projektu aplikacji we wszystkich dzierżawach.
Komunikacja z systemami spoza usługi IoT Central, na przykład na potrzeby długoterminowej analizy danych, wzdłuż zimnej ścieżki lub łączności z operacjami biznesowymi, odbywa się za pośrednictwem innych ofert PaaS i aPaaS firmy Microsoft. Te inne oferty mogą obejmować następujące usługi:
- Usługa Azure Event Hubs jako międzyplatformowy, korporacyjny silnik komunikacyjny i przepływu danych.
- Azure Logic Apps jako platforma integracji jako usługa (iPaaS).
- Usługa Azure Data Explorer jako platforma analizy danych.
- Usługa Power BI jako platforma wizualizacji i raportowania.
Jeśli porównasz podejście Simple SaaS z automatycznym modelem aPaaS z pojedynczą dzierżawą, wiele cech jest podobnych. Podstawową różnicą między dwoma modelami jest to, że:
- W zautomatyzowanym modelu pojedynczej dzierżawy wdrażasz odrębne wystąpienie usługi IoT Central dla każdej dzierżawy.
- W modelu Simple SaaS z usługą aPaaS wdrażasz współdzielone wystąpienie dla wielu klientów i tworzysz organizację w IoT Central dla każdego najemcy.
Ponieważ udostępniasz wielodostępną warstwę danych w tym modelu, musisz zaimplementować zabezpieczenia na poziomie wiersza, aby odizolować dane klientów. Aby dowiedzieć się więcej, zobacz Podejścia architektoniczne dla przechowywania i przetwarzania danych w wielodostępnych rozwiązaniach.
Korzyści:
- Łatwiejsze zarządzanie i obsługa względem innych przedstawionych tutaj metod.
Czynniki ryzyka:
Takie podejście może nie być łatwo skalować do dużej liczby urządzeń, komunikatów lub dzierżawców.
Usługi i składniki są współużytkowane, dlatego awaria w dowolnym składniku może mieć wpływ na wszystkich użytkowników. To ryzyko wiąże się z niezawodnością i wysoką dostępnością rozwiązania.
Ważne jest, aby wziąć pod uwagę sposób zarządzania zgodnością, operacjami, cyklem życia najemców i zabezpieczeniami podzestawów urządzeń. Te zagadnienia stają się ważne ze względu na wspólny charakter tego typu rozwiązania na płaszczyznach kontroli, zarządzania i komunikacji.
Horyzontalny SaaS
Cel wdrożenia | Model dzierżawy | Wzorzec wdrażania |
---|---|---|
Subskrypcja dostawcy usług | Podział poziomy | Sygnatura wdrożenia |
Typowym podejściem do skalowalności jest partycjonowanie rozwiązania w poziomie. Oznacza to, że masz niektóre składniki udostępnione i niektóre składniki dla poszczególnych klientów.
W ramach rozwiązania IoT istnieje wiele składników, które mogą być dzielone poziomo. Podsystemy partycjonowane w poziomie są zwykle rozmieszczone przy użyciu wzorca stempla wdrożenia, który integruje się z większym rozwiązaniem.
Przykład poziomy SaaS
Poniższy przykład architektury partycjonuje usługę IoT Central dla każdego klienta końcowego, który służy jako portal zarządzania urządzeniami, komunikacji urządzeń i administracji. Takie partycjonowanie jest często wykonywane w taki sposób, aby klient końcowy korzystający z rozwiązania miał pełną kontrolę nad dodawaniem, usuwaniem i aktualizowaniem swoich urządzeń bez interwencji dostawcy oprogramowania. Reszta rozwiązania jest zgodna ze standardowym wzorcem infrastruktury udostępnionej, który rozwiązuje potrzeby analizy ścieżki gorącej, integracji biznesowych, zarządzania SaaS i analizy urządzeń.
Każdy najemca ma własną organizację usługi IoT Central, która wysyła dane telemetryczne do udostępnionej aplikacji funkcji i udostępnia je użytkownikom biznesowym najemcy za pośrednictwem aplikacji internetowej.
Korzyści:
- Łatwe zarządzanie i obsługa, chociaż dodatkowe zarządzanie może być wymagane w przypadku składników z jedną dzierżawą.
- Elastyczne opcje skalowania, ponieważ warstwy są skalowane w razie potrzeby.
- Efekt awarii składników jest zmniejszony. Podczas gdy awaria wspólnego składnika wpływa na wszystkich klientów, komponenty skalowane horyzontalnie oddziałują tylko na klientów związanych z określonymi instancjami skalowania.
- Ulepszone szczegółowe informacje o użyciu dla pojedynczych dzierżawców dla partycjonowanych elementów.
- Partycjonowane składniki umożliwiają łatwiejsze dostosowanie dla każdego dzierżawcy.
Czynniki ryzyka:
- Skalowanie rozwiązania, szczególnie w przypadku jakichkolwiek składników udostępnionych.
- Może to mieć wpływ na niezawodność i wysoką dostępność. Jedna awaria w składnikach udostępnionych może wpływać na wszystkich najemców jednocześnie.
- Dostosowanie składnika partycjonowanego dla najemcy wymaga długoterminowego uwzględnienia zagadnień związanych z DevOps i zarządzaniem.
Poniżej przedstawiono najbardziej typowe składniki, które są zazwyczaj odpowiednie do partycjonowania poziomego.
Bazy danych
Możesz wybrać partycjonowanie baz danych. Często są to dane telemetryczne i magazyny danych urządzeń, które są partycjonowane. Często wiele magazynów danych jest używanych do różnych celów, takich jak ciepły lub archiwalny magazyn, lub informacje o stanie subskrypcji najmu.
Rozdziel bazy danych dla każdego lokatora, aby uzyskać następujące korzyści:
- Obsługa standardów zgodności. Dane każdego klienta są izolowane w różnych instancjach magazynu danych.
- Korygowanie hałaśliwych problemów z sąsiadem.
Zarządzanie urządzeniami, komunikacja i administracja
Aplikacje usługi Azure IoT Hub Device Provisioning Service, IoT Hub i IoT Central mogą być często wdrażane jako składniki podzielone poziomo. W tym rozwiązaniu potrzebna jest inna usługa do przekierowywania urządzeń do odpowiedniego wystąpienia usługi DPS dla płaszczyzny zarządzania, kontroli i telemetrii tego konkretnego dzierżawcy. Aby dowiedzieć się więcej, zobacz dokumentację Skalowanie rozwiązania Azure IoT w celu obsługi milionów urządzeń.
Takie podejście jest często podejmowane w celu umożliwienia klientom końcowym zarządzania własnymi flotami urządzeń, które są bardziej bezpośrednio i w pełni odizolowane.
Jeśli płaszczyzna komunikacji urządzeń jest partycjonowana horyzontalnie, dane telemetryczne muszą zostać wzbogacone o dane identyfikujące najemcę źródłowego. Funkcja ta pozwala procesorowi strumienia zidentyfikować reguły dzierżawy, które należy zastosować do strumienia danych. Na przykład, jeśli komunikat telemetrii generuje powiadomienie w procesorze strumienia, procesor strumienia musi ustalić właściwą ścieżkę powiadomienia dla powiązanego najemcy.
Przetwarzanie strumieniowe
Dzieląc przetwarzanie strumienia na części, można włączyć dostosowania analizy dla każdego dzierżawcy w procesorach strumieniowych.
Jedno-klientowy zautomatyzowany
Zautomatyzowane podejście z jedną dzierżawą opiera się na podobnym procesie podejmowania decyzji i projektowaniu rozwiązania dla przedsiębiorstw.
Każdy najemca ma własne, identyczne, izolowane środowisko z organizacją usługi IoT Central i innymi składnikami dedykowanymi im.
Cel wdrożenia | Model dzierżawy | Wzorzec wdrożenia |
---|---|---|
Subskrypcja dostawcy usług lub klienta | Jeden najemca na klienta | Uproszczony |
Krytycznym punktem decyzyjnym w tym podejściu jest wybór subskrypcji platformy Azure, do której mają być wdrażane składniki. Jeśli składniki są wdrażane w ramach Twojej subskrypcji, masz większą kontrolę i lepszy wgląd w koszt rozwiązania, ale wymaga to przejęcia większej odpowiedzialności za kwestie związane z bezpieczeństwem i zarządzaniem rozwiązaniem. Z drugiej strony, jeśli rozwiązanie jest wdrażane w ramach subskrypcji klienta, klient jest ostatecznie odpowiedzialny za bezpieczeństwo i nadzór nad wdrożeniem.
Ten wzorzec wspiera wysoki stopień skalowalności, ponieważ wymagania dotyczące dzierżawy i subskrypcji są zwykle czynnikami ograniczającymi w większości rozwiązań. W związku z tym izoluj każdą dzierżawę, aby zapewnić duży zakres skalowania obciążenia każdej dzierżawy, bez znacznego nakładu pracy ze strony dewelopera rozwiązań.
Ten wzorzec ma również małe opóźnienie w porównaniu z innymi wzorcami, ponieważ można wdrożyć składniki rozwiązania na podstawie lokalizacji geograficznej klientów. Koligacja geograficzna umożliwia krótsze ścieżki sieciowe między urządzeniem IoT a wdrożeniem platformy Azure.
W razie potrzeby można rozszerzyć wdrożenie automatyczne, aby obsługiwać lepsze opóźnienia lub skalę, włączając szybkie wdrażanie dodatkowych wystąpień rozwiązania w istniejących lub nowych lokalizacjach geograficznych.
Zautomatyzowane podejście z pojedynczym najemcą jest podobne do prostego modelu aPaaS SaaS. Podstawową różnicą między dwoma modelami jest to, że w zautomatyzowanym modelu z pojedynczą dzierżawą wdrażasz odrębne wystąpienie usługi IoT Central dla każdej dzierżawy, natomiast w modelu prostego SaaS z aPaaS wdrażasz współużytkowane wystąpienie usługi IoT Central dla wielu organizacji IoT Central.
Korzyści:
- Łatwe zarządzanie i obsługa.
- Izolacja najemcy jest gwarantowana.
Czynniki ryzyka:
- Początkowa automatyzacja może być skomplikowana dla nowych pracowników programistycznych.
- Należy wymusić zabezpieczenie poświadczeń pomiędzy klientami dla wyższego poziomu zarządzania wdrożeniami, w przeciwnym razie kompromitacje mogą rozprzestrzeniać się między klientami.
- Oczekuje się, że koszty będą wyższe, ponieważ korzyści ze skalowania udostępnionej infrastruktury między klientami nie są dostępne.
- Wiele wystąpień do utrzymania, jeśli dostawca rozwiązania jest odpowiedzialny za konserwację każdego wystąpienia.
Zwiększanie skali modelu SaaS
W przypadku rozszerzania skali rozwiązania do dużych wdrożeń istnieją konkretne wyzwania, które pojawiają się w oparciu o limity usług, problemy geograficzne i inne czynniki. Aby uzyskać więcej informacji na temat architektur wdrażania IoT na dużą skalę, zobacz Rozszerzanie rozwiązania Azure IoT w celu obsługi milionów urządzeń.
Współautorzy
Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.
Główni autorzy
- Michael C. Bazarewsky | Starszy inżynier klienta, fasttrack dla platformy Azure
- David Crook | Główny inżynier klienta, fasttrack dla platformy Azure
Inni współautorzy:
- John Downs | Główny inżynier oprogramowania
- Arsen Vladimirskiy | Główny inżynier klienta, fasttrack dla platformy Azure
Następne kroki
- Zapoznaj się ze wskazówkami dotyczącymi wielości użytkowników i usługi Azure Cosmos DB.
- Dowiedz się więcej o gorących, ciepłych i zimnych ścieżkach danych za pomocą usługi IoT na platformie Azure.