Publicera och prenumerera på MQTT-meddelanden med azure IoT MQ Preview

  • Artikel

Viktigt!

Förhandsversion av Azure IoT Operations – aktiverad av Azure Arc finns för närvarande i FÖRHANDSVERSION. Du bör inte använda den här förhandsgranskningsprogramvaran i produktionsmiljöer.

Juridiska villkor för Azure-funktioner i betaversion, förhandsversion eller som av någon annan anledning inte har gjorts allmänt tillgängliga ännu finns i kompletterande användningsvillkor för Microsoft Azure-förhandsversioner.

Förhandsversionen av Azure IoT MQ har en MQTT-mäklare i företagsklass som är skalbar, högtillgänglig och Kubernetes-inbyggd. Den tillhandahåller meddelandeplanet för Förhandsversionen av Azure IoT Operations, möjliggör dubbelriktad kommunikation mellan kanter/moln och driver händelsedrivna program vid gränsen.

MQTT-kompatibel

IoT MQ har en standardkompatibel MQTT Broker som stöder både MQTT v3.1.1 och MQTT v5.

Message Queue Telemetry Transport (MQTT) har dykt upp som lingua franca bland protokoll i IoT-utrymmet. MQTT:s enkla design gör det möjligt för en enda mäklare att betjäna tiotusentals klienter samtidigt, med en enkel publiceringsprenumerering där ämnet skapas och hanteras. Många IoT-enheter stöder MQTT internt out-of-the-box, med den långa svansen av IoT-protokoll som rationaliseras till MQTT av underordnade översättningsgatewayer.

IoT MQ använder MQTT-protokollet som grund för meddelandelagret. Mer information om MQTT-funktioner som stöds finns i MQTT-funktionsstöd i Azure IoT MQ Preview.

Mycket tillgänglig och lätt att skala

Kubernetes kan skala arbetsbelastningar horisontellt så att de körs i flera instanser. Den här redundansen innebär ytterligare kapacitet för att hantera begäranden och tillförlitlighet om någon instans slutar fungera. Kubernetes har inbyggd självåterställning och instanser återställs automatiskt.

Förutom att Kubernetes är en elastisk skalningsteknik är det också en standard för DevOps. Om MQTT är lingua franca bland IoT-protokoll är Kubernetes lingua franca för infrastrukturlager för databehandling. Genom att använda Kubernetes kan du använda samma CI/CD-pipeline, verktyg, övervakning, apppaketering, medarbetarfärdighet överallt. Resultatet är ett enda system från slutpunkt till slutpunkt från molnbaserad databehandling, lokala servrar och mindre IoT-gatewayer på fabriksgolvet. Du kan ägna mindre tid åt att hantera infrastruktur eller DevOps och fokusera på ditt företag.

Azure IoT MQ fokuserar på det unika gränsbaserade dataplansvärdet som det kan ge Kubernetes-ekosystemet samtidigt som det passar sömlöst in i det. Det ger hög prestanda och skalbart plattformsplan för meddelanden som bygger på MQTT och sömlös integrering med andra skalbara Kubernetes-arbetsbelastningar och Azure.

Säker som standard

IoT MQ bygger på stridstestade säkerhets- och identitetsbegrepp i Azure och Kubernetes, vilket gör det både mycket säkert och användbart. Den stöder flera autentiseringsmekanismer för flexibilitet tillsammans med detaljerade mekanismer för åtkomstkontroll hela vägen ned till en enskild MQTT-ämnesnivå.

Azure Arc-integrering

Microsofts hybridplattform är förankrad kring Kubernetes med Azure Arc som ett enda kontrollplan. Det tillhandahåller ett hanteringsplan som projicerar befintliga resurser som inte är Azure, lokala resurser eller andra molnresurser i Azure Resource Manager. Resultatet är ett enda kontrollfönster för att hantera virtuella datorer, Kubernetes-kluster och databaser som inte körs i Azure-datacenter.

IoT MQ distribueras som ett Azure Arc for Kubernetes-tillägg och kan hanteras via en fullständig azure-resursprovider (RP) – microsoft/IoTOperationsMQ. Det innebär att du kan hantera det precis som interna Azure-molnresurser som virtuella datorer, lagring osv.

Med Azure Arc-tekniken kan ändringarna börja gälla för IoT MQ-tjänster som körs i det lokala Kubernetes-klustret. Om du föredrar en helt Kubernetes-intern metod kan du hantera IoT MQ med Kubernetes anpassade resursdefinitioner (CRD) lokalt eller använda GitOps-tekniker som Flux.

Molnanslutningar

Du kan ha olika meddelandekrav för ditt molnscenario. Till exempel en dubbelriktad moln-/gränssnabb sökväg för högprioriterad data eller för att driva molninstrumentpaneler i nära realtid och en långsam sökväg till lägre kostnad för mindre tidskritiska data som kan uppdateras i batchar.

För att ge flexibilitet tillhandahåller Azure IoT MQ inbyggda Azure-Anslut orer till Event Hubs (med Kafka-slutpunkt), Event Grids MQTT-asynkron kapacitet, Microsoft Fabric och Blob Storage. IoT MQ är utökningsbar så att du kan välja önskad lösning för molnmeddelanden som fungerar med din lösning.

Genom att bygga vidare på Azure Arc kan anslutningsapparna konfigureras för att använda Azure Managed Identity för åtkomst till molntjänsterna med kraftfull Azure-rollbaserad åtkomstkontroll (RBAC). Ingen manuell, osäker och besvärlig hantering av autentiseringsuppgifter krävs.

Dapr-programmeringsmodell

Dapr förenklar VVS mellan distribuerade program genom att exponera vanliga distribuerade programfunktioner, till exempel tillståndshantering, tjänst-till-tjänst-anrop och publicera-prenumerera-meddelanden. Dapr-komponenterna ligger under byggstenarna och tillhandahåller en konkret implementering för varje funktion. Du kan fokusera på affärslogik och låta Dapr hantera distribuerad programinformation.

IoT MQ tillhandahåller anslutningsbara byggstenar för Publicering och prenumeration av dapr-prenumeration och tillståndslager, vilket gör utveckling och distribution av händelsedrivna program på gränsen enkel och teknikoberoende.

Arkitektur

MQTT-asynkron meddelandekö har tre lager:

  • Tillståndslöst klientdelslager som hanterar klientbegäranden
  • Lastbalanserare som dirigerar begäranden och ansluter asynkron meddelandekö till andra
  • Tillståndskänsligt och fragmenterat serverdelslager som lagrar och bearbetar data

Serverdelslagret partitioneras data efter olika nycklar, till exempel klient-ID för klientsessioner och ämnesnamn för ämnesmeddelanden. Den använder kedjereplikering för att replikera data inom varje partition. För data som delas av alla partitioner använder den en enda kedja som sträcker sig över alla partitioner.

Arkitekturens mål är:

  • Feltolerans och isolering: Meddelandepublicering fortsätter om serverdelsnoder misslyckas och förhindrar att fel sprids till resten av systemet
  • Återställning av fel: Automatisk felåterställning utan operatörsintervention
  • Ingen meddelandeförlust: Leverans av meddelanden om minst en klientdelsnod och en serverdelsnod körs
  • Elastisk skalning: Horisontell skalning av publicering och prenumererande dataflöde för att stödja gräns- och molndistributioner
  • Konsekvent prestanda i stor skala: Begränsa kostnaderna för meddelandefördröjning på grund av kedjereplikering
  • Drifts enkelhet: Minsta beroende av externa komponenter för att förenkla underhåll och komplexitet

Nästa steg

Distribuera Azure IoT Operations Preview-tillägg till ett Kubernetes-kluster