Azure Service Bus - Mehrere Themen?

Question

Also eine kurze Zusammenfassung dessen, was ich im Moment arbeite:

Ich entscheide, ob ich dies mit 1 Thema vs brauche N Themen und beide mit den relevanten Metadaten/Filter.

Ich habe 3 Stück ziemlich viel; ein Socket-Server (Worker-Rolle), zu dem Einheiten im Feld eine Verbindung herstellen, Azure Service Bus-Messaging und schließlich eine Web-App. Der Benutzer kann Befehle in die Warteschlange stellen, die über die Web-App an Geräte gesendet werden, aber wir müssen Nachrichten in der Warteschlange halten können, bis das Gerät online ist, von dem es dann alle Nachrichten erhält. Dies ist, wo ich verwirrt bin ...

Ich arbeitete zunächst entlang der Linien der dynamischen Erstellung von 1-9999 Themen (Limit von 10 000 Themen können erstellt werden, so dass die letzten 4 Zeichen der seriellen) in der Web-App auf Nachrichten werden in die Warteschlange gestellt. Die Geräte werden dann in den Metadaten vollständig seriell sein. Auf diese Art und Weise, wie Geräte mit dem Socket-Server verbunden werden, kann ich N-Subskriptionen mit bestimmten Regeln erstellen und sie herunterfahren, wenn die Geräte getrennt werden.

Aber jetzt frage ich mich, ob ich nur 1 Thema hätte und die ganze Logik in den Metadaten platzieren könnte?

Ich bin sehr neu für SQLFilters mit Linienbus so würde jede Hilfe sehr :)

Answer 1

Gute Frage geschätzt! Zuallererst sollte ich sagen, dass ich IoT Hubs in Ihrer Situation verwenden würde, was der "Warteschlangen" -ähnliche Dienst ist, der für IoT-Szenarien optimiert ist, einschließlich Management und Befehlen. Oder Event-Hubs, aber sie sind weniger Befehlsmuster optimiert.

1) Ereignis-Hub

2) IoT Hub

Die erste für die Szenarien ist, die mehr sind Ereignisse orientiert. Was ich meine - die Verwaltung des Geräts aus dem Backend zu implementieren wird komplexer mit den Event Hubs und weniger komplex mit den IoT Hubs.

Ich kann Ihnen wärmstens empfehlen, sich diese Dienste anzusehen, denn Service Bus ist der großartige Service, aber die aufgeführten Dienste sind eher IoT-orientiert.

Aus der Sicht der Architektur hat Microsoft kürzlich das Whitepaper IoT Reference Architecture veröffentlicht, das Sie hier herunterladen können. Es enthält die Empfehlungen, Dienste, Best Practices usw., die für die Azure + IoT-Projekte aus der Sicht von Microsoft verwendet werden können.

Eine andere hilfreiche Ressource könnte http://azureiotsuite.com sein. Es ist die Referenz-IoT-Architektur implementiert. Wenn Sie also auf "Erstellen" klicken, verfügen Sie in Ihrem Azure-Abonnement über eine von zwei Referenzarchitekturen (Remoteüberwachung oder vorausschauende Wartung), und Sie können alle Datenflüsse überprüfen.

Daher würde ich empfehlen, IoT/Event Hubs anstelle der SB Topics/Queues zu verwenden, da im IoT-Feld der für diese Workloads optimierte Service besser funktionieren sollte als anfänglich nicht optimiert.

Zweitens, Sie haben nicht angegeben, wie Sie Ihre Geräte mit der Worker Role verbinden, so wie ich sah, gibt es eine gute Bibliothek dafür, dass SuperSocket genannt.

So, wie ich Ihre Lösung Architektur sehen kann sieht aus wie:

Gerät 2 Cloud:

Devices => Gateway (Supersocket oder was auch immer) || IoT Hub => Geräte Registry (siehe Links oben angegeben)

Cloud 2 Device:

User Interface => IoT Hub mit eingetragenem device => Gerät

Geräte Registry ist bequeme Weise zu tun das IoT fließt als das Übertragen von IDs oder usw. Dynamische Erstellung von Entitäten hat einige Nachteile - stellen Sie sich vor, wenn der Erstellungsbefehl zum Beispiel einen Zeitüberschreitungsfehler zurückgibt. Es ist besser, optimierte Dienste zu nutzen, glaube ich.

Wenn das Gerät offline ist, wird die Warteschlange nicht abgefragt. Nachrichten haben eine gewisse Aufbewahrungszeit, bevor sie blockiert werden, das ist der eingebaute Mechanismus.