Dieser Artikel wurde maschinell übersetzt.

Windows Azure 內行人

Windows Azure Service Bus und das Internet der Dinge

Bruno Terkaly
Ricardo Villalobos

Machine-to-Machine (M2M) computing ist schnell zu einer Technologie, die alle Entwickler und Architekten benötigen, zu umarmen.Zahlreiche Studien deuten darauf hin,einer kommenden Welt in zweistelliger Milliardenhöhe Geräte (ein halbes Dutzend für jeden Menschen auf der Erde) bis 2020 (bit.ly/M2qBII).Ein Grund, warum diesgeschieht ist weil sie nie für Garage Bastler und Hobbyprogrammierer Prototyp ein Verbraucher oder kommerzielle Vorrichtung zur späteren Herstellung und den Verkauf einfacher wurde.Erste Schritte mit der Hardware und die Software ist unglaublich günstig.Für weniger als $100 bestellen Sie ein Arduino oder ein Himbeer-PI.

Aber man bekommt was man bezahlt und diese Geräte — vor allem dem Arduino — unteren Ende des Spektrums Gerätefunktion darstellen.Mit 32KB Flash-Speicherund 4KB RAM es fehlen die Macht, alles andere als die einfachsten Aspekte eines Web-Stack ausgeführt.Arduino ist eine open-Source-Mikrocontroller mit einemkleinen Chip, Speicher und Speicher ausgestattet.Die Software besteht aus einem standard-Programmiersprache-Compiler und einen Boot-Loader, der auf demMikrocontroller ausführt.Sie können hinzufügen, dass Expansion boards, die Stecker in das Gerät, Motorsteuerungen, GPS, Ethernet, ein LCD-Display, Sensoren,Aktoren und mehr anschließen.Ein wenig mehr Geld zu bezahlen und Sie können die leistungsfähigere Himbeer-PI, die mit einer Version von GNU/Linux-Betriebssystemund 256 KB RAM kommt.

Diese Geräte haben nur selten den Wert, wenn sie an etwas anderes angeschlossen sind, vielleicht eine Wolke back-End, die Daten empfängt und sendet Befehle.Aber verbinden mit, Kommunikation mit undverwalten diese Geräte über eine Anwendung in der Cloud stellt eine besondere Herausforderung.Die schiere Anzahl der Geräte, sowie ihre begrenzte Akkulaufzeit und Bandbreite, erzwingt einen Cloud-Entwickler alle Optionen sorgfältig zu prüfen.

In diesem Artikel nehmen wir einen Blick auf wie Entwickler versuchen, die wichtigsten Herausforderungen der Adressierbarkeit, Bandbreite und Sicherheit zu überwinden.Wir werden den Mythos entlarven, dassIPv6 und virtuelle private Netzwerke (VPNs) einfache, effiziente und sichere sind und vorschlagen werden, dass der Windows Azure Service Bus das perfekte Produkt ist, elegant diese Herausforderungen zu meistern.Fahren einige der Konzepte Hause, präsentieren wir Ihnen vier Muster, die Sie auf Ihrem Clientgerät verwenden können, bei der Kommunikation mit dem Cloud-Back-End.Schließlich stellen wir einekurze Einführung in Service Bus Unterstützung für das Advanced Message Queuing Protocol (AMQP) 1.0 — eine interoperable und effiziente Protokoll für Gerät-zu-Cloud Kommunikation.

Seit vielen Jahren bedeutete die sichere Verbindungen über TCP/IP mit IPv4, kombiniert mit VPNs.Das einigermaßen gut funktioniert, aber jetzt zeigt Anzeichen des Alters.Für den Anfang ist es schwierig, eineeindeutige IP-Adresse im öffentlichen Internet mit einem Gerät raus — wir haben ziemlich viel laufen von IP-Adressen.Eingefleischte Fans von diesem Ansatz Versprechen, dass IPv6 zu Hilfe kommen wird.Diegängige Meinung ist, dass wenn Sie dem Gerät eine eindeutige IP-Adresse geben, alle Ihre Probleme gelöst werden.Leider löst dies nur einen kleinen Teil des Gesamtproblems.Geben jedes Gerät eine eigeneeindeutige IP-Adresse ist definitiv nicht die Wunderwaffe, die viele gehofft hatten.

Nur um das klarzustellen, sind IPv6 und VPNs voller Probleme in einer Welt voll, angeschlossenes Speichergerät.Bandbreite, ist vor allem eine Herausforderung.Gesprächig-Verbindung zwischen Gerät undNetzwerk kann zu übermäßigen Verkehr führen.Darüber hinaus Ansätze mit typischen HTTP-Anforderung/Antwort für alle messaging-Kanalisation-Akkulaufzeit auf vielen Geräten.Vielleicht am wichtigsten ist,dass Sicherheit nicht garantiert werden kann.VPNs sind definitiv unsicher, in einigen Szenarien.Bevor eine Lösung präsentieren, wir tauchen ein wenig tiefer und erkunden Sie diese Probleme.

Geräte erstellen, übermäßigem Netzwerkverkehr, die Kommunikation mit der Wolke zurück Ende sind problematisch.Bandbreite kosten Geld, möglicherweise eine Menge Geld, wenn es viele sehr gesprächigGeräte gibt.Darüber hinaus bedeutet mehr Daten mehr CPU-Nutzung, d.h. mehr Energie, eine wertvolle Ressource auf einem mobilen Gerät.Die meisten batteriebetriebene Geräte ausgestattet mit einem Wi-Fi-Transmitter und eine SIM-Karte müssen geben einen Low-Power-"Schlaf"-Modus, Zeiten, wenn sie senden oder empfangen von Daten sind nicht.Der IEEE 802.11-Standard definiert diese Power-Save Polling-Funktion.Wenn das Gerät im Ruhezustand befindet, ruft die Daten gepuffert.Sobald es erwacht, werden die gepufferten Daten geliefert.Gesprächig Netzwerke Puffer zu füllen und vorzeitig wecken schlafendeGeräte.

HTTP-Anforderung/Antwort-Ansätze sind lächerlich verschwenderisch, angesichts der Größe der Nutzlast im Verhältnis zu den gesamten HTTP Anfrage -­Antwort Infrastruktur.Angenommen Sie, ein Gerät musseinfach nur auf der Wolke, gemeldet, wie z. B. Temperatur, Druck oder GPS zu koordinieren.Binärdaten ist wahrscheinlich nur ein paar Bytes in Größe, aber der HTTP-POST ist in der Regel mindestens 500-1.000 Bytes, mit der Anfrage-Header allein reicht von 200 bis 2.000 Bytes.Einige Entwickler gebrauchen die Tricks, wie die Füllung alles in den HTTP-Header, den Aufwand für den Körperteil der HTTP-Anforderung zu vermeiden.Aber das reicht nicht aus, und die Größe der HTTP-Anforderung nur größer wird, wenn Sie Anmeldeinformationen zu übertragen.

Hier ist einige einfache mathematische, Sie zu überzeugen.Stellen Sie sich Ihr Gerät Temperaturdaten alle 5 Sekunden senden und die Nutzlast für die Temperaturdaten ist eine großzügige 20 Byte.In einem 24-Stunden-Zeitraum würde die Temperaturdaten von selbst vom Gerät zur Wolke etwa 350.000 Bytes übertragen.Wenn Sie in der HTTP-Anforderung/Antwort-Umschlag hinzufügen, erhöhe jeder Übertragung um800 Bytes, einen Faktor von 41, Senden von mehr als 14MB an der Wolke statt nur die 350 KB von Temperaturdaten.Dies erhalten unerschwinglich teuer, wenn Sie Tausende von Geräten unterstützen.

Vielleicht ist das größte Missverständnis, dass VPNs inhärent sicher sind.Die Realität ist, dass VPN-Netzwerke riskant sind, vor allem, wenn ein VPN verbundenen Geräte außerhalb des Herstellers oderBetreibers unmittelbare physische Kontrolle sind.Sobald ein einzelnes Gerät überschritten wird, sind alle Geräte mit dem gleichen VPN anfällig.Sobald ein nicht vertrauenswürdiger Benutzer Zugriff auf einangeschlossenes Gerät bekommt, können er oder sie das Gerät zu erforschen und Ihre internen Ressourcen anzugreifen.Trotz dieser Mängel sind VPNs oft die einzige Möglichkeit, die von vielen Trägernangeboten.

Die Windows Azure Service-Bus-Ansatz

Windows Azure Service Bus bietet einige großartigen Lösungen für diese Herausforderungen.Nutzung der Service-Bus ist sicherer, da das Gerät ist nur ein Endpunkt im Internet können sie Nachrichten in einerWarteschlange platzieren.Das Gerät kann nicht anderen geschützten Netzwerk-Ressourcen innerhalb der Cloud-Services erreichen.Außerdem Nachrichten über den Service Bus Gerät Verbindungskostenweniger in Bezug auf Leistung, weil das Gerät öfter schlafen kann, in regelmäßigen Abständen alle wartenden ziehen Aufwachen aus der Warteschlange.

Service Bus bietet noch mehr Wert, denn es kann:

• Entkoppeln Sie Gerätekommunikation und Interaktion von Cloud-service
• Abgleich u. Lastenausgleich zwischen mehreren Instanzen von Ihren Back-End-Dienst zu aktivieren
• Doppelte Nachrichten zu identifizieren
• Sammeln von Nachrichten in logische Gruppen (so genannte Sessions)
• Transaktionales Verhalten und Unteilbarkeit implementieren
• Geordnete Übermittlung von Nachrichten unterstützen und bieten ein Time-to-live, für jede Nachricht
• Um publish / subscribe-Szenarien, die leicht mit Themen und Abonnements verlängern

Um eine konkretere Vorstellung davon, wie ein Gerät mit verbunden und kommuniziert mit dem Cloud-Backend zu erhalten, schauen Sie sich Abbildung 1, die zeigt, wie ein spezieller Gerät in eine größereArchitektur passen könnte.Wir verwenden das kanonische Beispiel OpenSprinkler, ein open-Source Internet-basierte Sprengerbewässerung/Ventilsteuerung, die das Wetter zu überprüfen, bevor Sie sichentscheiden, auf dem Wasser machen kann.Es ist mit Arduino Teile gebaut.Hinweis: in Abbildung 1 , dass dem Arduino steuert die Sprinkleranlage über ein Heimnetzwerk als die Internet-Verbindung und miteinem Cloud-Back-End kommuniziert.

Abbildung 1 Arduino Sprinkler System Reference Architecture

Lösen Probleme mit der Netzwerkkonnektivität

Windows Azure Service-Bus hat eine große Aufgabe die Adressierbarkeit und Netzwerk-Konnektivität Herausforderungen zu lösen.Das Arduino-Gerät saß wahrscheinlich hinter einigen NAT-Schicht, macht esschwierig, von einem Cloud-Service zu erreichen.Glücklicherweise vereinfacht den Service Bus Konnektivität durch als ein Relay-Dienst und als Proxy für eine Wolke-Back-End servieren.Darüber hinaus kannbieten Warteschlangen, Themen und Abonnements, die es als Drehscheibe zwischen der Wolke und dem Gerät gesendeten Nachrichten Ereignis handeln ermöglicht.Die entkoppelte Natur einer Warteschlangeals ein Relais kann das Gerät asynchron senden und empfangen von Nachrichten in und aus der Wolke, auch wenn nur gelegentlich verbunden.Aus Sicherheitsgründen kann das Gerät mitSharedAccessSignature, GemeinsamerGeheimerSchlüssel, SAML oder SimpleWebToken authentifiziert werden.

Beachten Sie im Abbildung 1, dass eine oder mehrere Worker-Funktionen aus der Service Bus Nachrichten lesen können.Worker-Funktionen können Entscheidungen und Befehle zurück auf das Gerät.AndereWorker-Funktionen könnten Wetterinformationen aus anderen Systemen, wie z. B. der National Weather Service bekommen.Worker-Funktionen können die unverarbeitete eingehende Ereignisse auch in eineNoSQL-Datenbank, wie z. B. MongoDB sparen.

Abbildung 1 zeigt auch mobile Benutzer interagieren mit Webrollen Bewässerung planen.Mobile Benutzer erhalten Push-Benachrichtigungen von Windows Azure Mobile Services (WAMS), die alle wichtigenBenachrichtigung-Netzwerke wie Windows Notification Services (WNS), Microsoft Push Notification Service (MPNS), Apple Push Notification Service (APNS) und Google Cloud Messaging für Android (GCM) unterstützt.WAMS erleichtert die Unterstützung von Windows, iOS und Android.

Sie können sogar einen Maschinelles Lernen Teil der Architektur vorstellen.Windows Azure unterstützt Linux-VMs und es ist ganz einfach PyMongo (ein Python-Treiber für MongoDB) konfigurieren, um zulesen, der Ereignisstream von diversen Geräten produziert und Maschinelles Lernen Techniken in PyML verwenden, um Muster oder Prognosen über die Ereignis-Stream-Daten.Auf der Grundlage bestimmterVorhersagen oder Muster können Cloud-Service zum Senden von Befehlen an das Gerät, z. B. einschalten oder Ausschalten des Wassers.

Ein Messagingsystem, das ist der primäre Endpunkt für das Senden und empfangen von Daten ist erweiterbar, da Geräte können weiterhin einen einzelne Nachricht-Stream zu senden, während neueAbonnements zu einem Service-Bus-Thema für jedes neue System hinzugefügt werden können, die diesem Nachrichtenstrom beanspruchen wird.Diese Systeme können für Echtzeit-Analysen sowieMaschinelles Lernen und andere Szenarien wie oben beschrieben werden.

Kommunikation mit der Wolke

Es gibt vier Muster, die auf dem Client für die Kommunikation mit den Cloud-Dienst verwendet werden können.Diese sind gemäß Abbildung 2.

Abbildung 2 vier Muster für Gerät-Cloud-Service-Kommunikation

Alle vier Muster nutzen Service Bus Themen und Abonnements.Abhängig von der Richtung der Kommunikation (Gerät cloud Service oder cloud-Service zum Gerät) kann das Gerät entweder abonnieren Themenoder zu Themen veröffentlichen.Themen sind einfach ein Mechanismus zum Senden von Nachrichten, während Abonnements verwendet werden, um Nachrichten zu verbrauchen.Filter-Regeln für Abonnementsum weitere feingranulare Kontrolle zu ermöglichen, über die Nachrichten abgerufen werden, können.Worker-Funktionen in der Cloud-Service können verwendet werden, um Nachrichten zu Themen veröffentlichenoder Nachrichten aus Abonnements belegen.

Aus Platzgründen kann nicht wir zeigen alle die Muster hier in diesem Artikel so dass wir in nur einer beschäftigen werde.Abbildung 3 zeigt eine Referenz-Implementierung des Musters Befehl.Es zeigt, dassdie Geräte von Gebäude 1 und 2 können abonnieren Sie Nachrichten (Befehle) und Antworten zurück zu Themen Posten.Beachten Sie, dass Worker-Funktionen in der Cloud-Service eine Temperatur-undSchatten Befehl Thema Nachrichten veröffentlichen können und bestimmte Geräte separat Temperatur oder Farbkontrolle Nachrichten abonnieren können.Service Bus Themen und Abonnements können in einerVielzahl von Kombinationen verwendet werden, um den Nachrichtenfluss entsprechend zu partitionieren.

Abbildung 3-Architektur für das Command-Pattern

AMQP und Verbundfähigkeit

Das Windows Azure Service-Bus-Team hat vor kurzem angekündigt, Unterstützung für das Advanced Message Queuing Protocol (AMQP) 1.0, ein offener Standard mit einer binären Anwendungsschicht fürnachrichtenorientierte Middleware.Der wichtigste Wert ist, dass es hochgradig interoperabel ist und es ein binäres Format auf dem Draht verwendet, Nutzlastgröße zu minimieren.

AMQP unterstützt zuverlässige Nachrichtenübertragung, queuing, routing, Pub/Sub und vieles mehr.Da es ein niedriger Ebene-Protokoll auf Daten-streaming über das Netzwerk ist, kann alle kompatiblen Toolmit den Daten unabhängig von der Implementierungssprache interagieren.Dadurch Plattform-und Hybridanwendungen, die ein offenes, standard-Protokoll verwenden.Die Bibliothek können Sie Mix und Match-Sprachen, Frameworks und Betriebssysteme, .NET, Java, Python und PHP zu unterstützen.Sie finden weitere Informationen auf der Seite Windows-Azure- Beispiele bei aka.ms/G3izk8.Entwickelt, um Lichtund inter­bedienbar, AMQP ist eine gute Passform für viele der heutigen Geräte benötigen Konnektivität zu einem Cloud-Back-End.

AMQP ist jedoch zu viel Software für heutige Arduino, die die erforderlichen Speicher, Speicher und Verarbeitungsleistung fehlt.Unter AMQP muss Unterstützung für Transport Layer Security (TLS), einkryptografisches Protokoll com­Sicherheit der Kommunikation über TCP.TLS verwendet x. 509 Zertifikate (asymmetrische Kryptographie) überprüfen die Identität der Parteien über das Netz zu kommunizieren.Darüber hinaus wird die Apache gefangen in der Vergangenheit Proton Client-basierte messaging-Bibliothek oft mit AMQP zur Vereinfachung der Kommunikation über Router, Brücken und Proxys zu integrieren.All dies wirft die Frage: Wie unterstützen Sie Low-End-Geräte-Back-Ends Cloud genießen die Vorteile der Service Bus Messaginginfrastruktur anschließen?

Eine Option ist mehr Geld zu bezahlen und erhalten eine Himbeer-PI.Wenn Sie nicht, dass zu tun möchten, müssen Sie mehr kreativ zu sein.Kann man durch die Nutzung von Clemens Vasters' code beibit.ly/1acvLdS, die können einem Arduino einen Befehl zu einem LED-Licht auf dem Mikrocontroller zu blinken.Der Code implementiert eine Device Gateway, die einen TCP-Endpunkt, den dem Arduinoverbunden.Um die Verbindung durch NATs und der Windows-Azure-Load-Balancer zu erhalten, muss der Cloud-Service dem Arduino ping alle 235 Sekunden (knapp 4 Minuten).Siehe Vasters c#-ProjektLedBlinkerServer.

In unseren nächsten Artikel nehmen wir einen tieferen Tauchgang zu erklären, wie der Code funktioniert, und wie kann man dem Arduino zum Senden und empfangen von Nachrichten zu und von den ServiceBus.

Zusammenfassung

Im Artikel dieses Monats vorgestellt wir vier Muster, die verwendet werden können, baut eine Reli­in der Lage Nachrichtenaustausch zwischen einem Gerät und Cloud-Services.Wir führten AMQP, das open-Source Message queuing-Protokoll, das hilft, Interoperabilität zu erhöhen und minimieren Sie Bandbreite und wird vollständig durch den Windows Azure Service-Bus unterstützt.Schließlich begannen wirdiskutieren, wie Low-End-Geräte verbinden Cloud Back-Ends während der Verwendung des Service Bus messaging-Infrastruktur, die wir in unserem nächsten Artikel werde auch weiterhin zu unterstützen.

Wir danken Clemens Vasters und Abhishek Lal helfen uns zu verstehen, die schöne neue Welt der angeschlossenen Geräte.Klar, wächst die Welt der spezielle Geräte mit Cloud-Services verbunden.Traditionelle Ansätze zur Kommunikation mit einem Cloud-Dienst müssen neu bewertet werden.Sicherheit, Bandbreite, Zuverlässigkeit und Interoperabilität sind nur einige der Herausforderungen für dieArchitekten und Entwickler mit spezieller Geräte in der M2M-Welt.Mit der Windows Azure Service Bus macht diese Herausforderungen weit weniger abschreckend.

Bruno Terkaly ist ein Developer Evangelist für Microsoft. Sein tiefes Wissen kommt aus jahrelanger Erfahrung im Feld Code mit einer Vielzahl von Plattformen, Sprachen, Frameworks, SDKs, Bibliothekenund APIs. Er verbringt Zeit Schreiben von Code, Blogging und geben live-Präsentationen auf den Aufbau von Cloud-basierten Anwendungen, speziell mit der Windows Azure-Plattform. Sie können lesen Sie seinen Blog unter blogs.msdn.com/b/brunoterkaly.

Ricardo Villalobos ist ein erfahrener Softwarearchitekt mit mehr als 15 Jahren Erfahrung im Entwerfen und Erstellen von Anwendungen für Unternehmen in verschiedenen Branchen. Halten verschiedenetechnische Zertifizierungen, sowie einen Master-Abschluss in Betriebswirtschaft von der Universität Dallas, arbeitet er als Architekt Wolke in der DPE weltweit engagierten Partner-Team für Microsoft, hilft Unternehmen weltweit, in Windows Azure Lösungen zu implementieren. Sie können lesen Sie seinen Blog unter blog.ricardovillalobos.com.

Terkaly und Villalobos präsentieren gemeinsam bei großen Konferenzen.Sie ermutigen die Leser des Windows Azure-Insider zu ihnen Verfügbarkeit erhalten.Terkaly kann erreicht werden unterbterkaly@microsoft.com und Villalobos kann erreicht werden unter Ricardo.Villalobos@microsoft.com.

Unser Dank gilt den folgenden technischen Experten von Microsoft für die Durchsicht dieses Artikels: Abhishek Lal und Clemens Vasters