Teilen des Standorts in Echtzeit mithilfe kostengünstiger serverloser Azure-Dienste

Front Door
Functions
Service Bus

In diesem Szenario wird die Erstellung einer Lösung beschrieben, die Änderungen an zugrunde liegenden Daten in einer Webansicht verarbeitet, ohne dafür eine Seitenaktualisierung mithilfe von Echtzeitdiensten zu erfordern. Beispiele für dieses Szenario sind die Echtzeitverfolgung von Produkten und Waren sowie Lösungen für soziale Medien.

In diesem Szenario richten wir einen Echtzeit-Messagingdienst zum Teilen des aktuellen Standorts einer Transaktion eines Lebensmittel-Lieferservice ein. Dieses Beispiel kann auch für Benutzer nützlich sein, die eine Plattform für die Echtzeit-Standortfreigabe für ihre Webanwendungen oder mobilen Anwendungen erstellen möchten.

Wir verwenden einen im serverlosen Modus konfigurierten SignalR-Dienst zur Integration in eine von Service Bus ausgelöste Azure Functions-App. Für das gesamte Szenario wird .NET Core verwendet.

Mögliche Anwendungsfälle

Folgende Anwendungsfälle verfügen über ähnliche Entwurfsmuster:

  • Teilen des Echtzeitstandorts mit Clientgeräten
  • Pushen von Benachrichtigungen an Benutzer
  • Aktualisieren von Zeitplänen
  • Erstellen von Chaträumen

Aufbau

Architekturdiagramm: Freigabe des Echtzeitstandorts durch Service Bus-Warteschlange, Azure Functions und SignalR

Komponenten

  • Service Bus ist ein äußerst zuverlässiger Cloudmessagingdienst zwischen Anwendungen und Diensten – auch wenn mehrere davon offline sind.
  • SignalR ermöglicht auf einfache Weise die Echtzeitkommunikation mit Ihrer Webanwendung.
  • Azure Functions ist eine Plattform für ereignisgesteuertes serverloses Compute, mit der Sie auch komplexeste Orchestrierungsprobleme lösen können.

Überlegungen

Im Folgenden werden einige der Überlegungen zur Entwicklung dieses Szenarios beschrieben, einschließlich der Konfiguration von Parametern in der Azure Service Bus-Verbindungszeichenfolge im ServiceBusTrigger:

Hubs: Hubs sind mit einem Videostreamingdienst vergleichbar. Sie können den Hub abonnieren, um Nachrichten an ihn zu senden bzw. von ihm zu empfangen.

Ziele: Ziele sind wie Radiokanäle. Jeder, der am Zielkanal lauscht, wird benachrichtigt, wenn eine neue Nachricht vorhanden ist.

Mit den beiden oben genannten Features der SignalR-Plattform können Sie die Lösung einfach und schnell in Betrieb nehmen.

Verfügbarkeit, Skalierbarkeit und Sicherheit

Mit den folgenden Schritten können Sie für diese Lösung Hochverfügbarkeit erzielen:

Regionspaare

Jede Azure-Region ist mit einer anderen Region innerhalb desselben Gebiets gepaart. Sie wählen im Allgemeinen Regionen aus dem gleichen Regionspaar aus (z.B. „USA, Osten 2“ und „USA, Mitte“). Das bietet die folgenden Vorteile:

  • Bei einem umfassenden Ausfall wird die Wiederherstellung mindestens einer Region aus jedem Paar priorisiert.
  • Geplante Azure-Systemupdates werden in Regionspaaren nacheinander ausgeführt, um mögliche Ausfallzeiten zu minimieren.
  • In den meisten Fällen befinden sich Regionspaare innerhalb desselben geografischen Gebiets, um spezifische regionale Anforderungen zu erfüllen.
  • Sie sollten allerdings sicherstellen, dass beide Regionen alle Azure-Dienste, die für Ihre Anwendung erforderlich sind, unterstützen. Weitere Informationen finden Sie unter Dienste nach Region. Weitere Informationen zu Regionspaaren finden Sie unter Geschäftskontinuität und Notfallwiederherstellung: Azure-Regionspaare.

Azure Front Door

Architekturdiagramm: Bereitstellen von Hochverfügbarkeit für eine mobile App durch Azure Front Door

Azure Front Door ist ein skalierbarer und sicherer Einstiegspunkt für die schnelle Bereitstellung Ihrer globalen Anwendungen. Der Dienst führt mit prioritätsbasiertem Routing automatisch ein Failover aus, wenn die primäre Region nicht mehr verfügbar ist. Eine Architektur mit mehreren Regionen kann eine höhere Verfügbarkeit als eine Bereitstellung in einer einzelnen Region bieten. Wenn ein regionaler Ausfall die primäre Region beeinträchtigt, können Sie mit Front Door ein Failover zur sekundären Region ausführen. Diese Architektur kann auch hilfreich sein, wenn ein einzelnes Subsystem der Lösung ausfällt. Stoppen Sie Angriffe auf Netzwerk- und Anwendungsebene am Edge mit Web Application Firewall und DDoS Protection. Verstärken Sie den Schutz Ihres Diensts mit von Microsoft verwalteten Regelsätzen, und erstellen Sie eigene Regeln für einen benutzerdefinierten Schutz Ihrer App.

Front Door ist eine potenzielle Fehlerquelle im System. Wenn beim Dienst ein Fehler auftritt, können Clients während der Ausfallzeit nicht auf Ihre Anwendung zugreifen. In der Vereinbarung zum Servicelevel (SLA) für Front Door erfahren Sie, ob Ihre geschäftlichen Anforderungen für Hochverfügbarkeit mit Front Door allein erfüllt werden. Wenn dies nicht der Fall ist, erwägen Sie als Alternative eine andere Verwaltungslösung für den Datenverkehr. Wenn der Front Door-Dienst fehlerhaft ist, ändern Sie die kanonischen Namensdatensätze (CNAME) im DNS, sodass sie auf die andere Verwaltungslösung für den Datenverkehr verweisen. Dieser Schritt muss manuell durchgeführt werden. Bis die DNS-Änderungen weitergegeben wurden, ist die Anwendung nicht verfügbar.

Preise für dieses Szenario

Angenommen, Ihr Unternehmen hat täglich 1.000 Bestellungen und muss für alle Bestellungen gleichzeitig Standortdaten teilen. Basierend auf den Preisen zum Zeitpunkt der Erstellung dieses Artikels liegt Ihre geschätzte Azure-Nutzung für die Bereitstellung dieses Szenarios bei etwa 192 USD pro Monat.

Dienstart Geschätzte monatliche Kosten
Azure-Funktionen 119,40 USD
Azure SignalR Service 48,97 USD
Service Bus 23,71 USD
Gesamt 192,08 USD

Bereitstellen dieses Szenarios

Azure Functions-Entwicklung

Eine serverlose Echtzeitanwendung, die mit Azure Functions und Azure SignalR Service erstellt wird, benötigt in der Regel zwei Azure-Funktionen:

  • Eine Aushandlungsfunktion, die der Client aufruft, um ein gültiges SignalR Service-Zugriffstoken und eine Dienstendpunkt-URL zu erhalten
  • Mindestens eine Funktion, die Nachrichten sendet oder die Gruppenmitgliedschaft verwaltet

FunctionApp6

Dies ist eine Funktions-App, die eine Azure-Funktion mit Service Bus-Trigger mit SignalR erstellt.

Negotiate.cs

Diese Funktion wird durch eine HTTP-Anforderung ausgelöst. Clientanwendungen rufen mit dieser Funktion ein Token vom SignalR-Dienst ab, das Clients zum Abonnieren eines Hubs verwenden können. Für diese Funktion sollte der Name „negotiate“ verwendet werden. Weitere Informationen finden Sie in diesem Leitfaden.

Message.cs

Diese Funktion wird von einem Service Bus-Trigger ausgelöst. Sie weist eine Bindung an den SignalR-Dienst auf. Die Funktion pullt die Nachricht aus der Warteschlange und übergibt sie an einen SignalR-Hub.

Instructions

  1. Stellen Sie sicher, dass Sie eine Service Bus-Warteschlange in Azure bereitgestellt haben.
  2. Stellen Sie sicher, dass Sie einen SignalR-Dienst im serverlosen Modus in Azure bereitgestellt haben.
  3. Geben Sie Ihre Verbindungszeichenfolgen (Service Bus und SignalR) in der Datei „local.settings.json“ ein.
  4. Geben Sie die URL der Clientanwendung (SignalR-Client) in CORS ein. In dieser Anleitung wird die aktuellste Syntax gezeigt.
  5. Geben Sie den Namen Ihrer Service Bus-Warteschlange im Service Bus-Trigger in der Datei „Message.cs“ ein.

Nun konfigurieren wir die Clientanwendung zum Testen. Rufen Sie zunächst die Beispielquellen ab, die Sie hier finden.

SignalR-Client

Dies ist eine einfache .NET Core-Webanwendung, mit der Sie den von FunctionApp6 erstellten Hub abonnieren und die in der Service Bus-Warteschlange empfangenen Nachrichten in Echtzeit anzeigen. Sie können FunctionApp6 mit einem mobilen Client verwenden, bei diesem Repository arbeiten wir jedoch mit dem Webclient.

Instructions

  1. Stellen Sie zunächst sicher, dass FunctionApp6 ausgeführt wird.
  2. Kopieren Sie die von der Negotiate-Funktion generierte URL. Sie sieht ungefähr wie folgt aus: http://localhost:7071/api/
  3. Fügen Sie die URL in „chat.js“ innerhalb von signalR.HubConnectionBuilder().withUrl("YOUR_URL_HERE").build(); ein.
  4. Führen Sie die Anwendung aus.
  5. Wenn der Webclient den SignalR-Hub erfolgreich abonniert hat, wird der Status „Verbunden“ angezeigt.

SendToQueue.js

Dieses Node.js-Skript pusht eine Nachricht an die Service Bus-Warteschlange, damit Sie die obige Bereitstellung testen können.

Instructions

  1. Installieren Sie das Node.js-Modul „Azure Service Bus“ (@azure/service-bus).
  2. Geben Sie Ihre Verbindungszeichenfolgen und den Warteschlangennamen im Skript ein.
  3. Führen Sie das Skript aus.

Nächste Schritte

Sie können dieses Szenario in Ihrer Produktionsumgebung verwenden, stellen Sie aber sicher, dass Ihre Azure-Dienste zur Skalierung eingerichtet sind. Beispielsweise sollte Ihre Azure Service Bus-Instanz auf einen Standard- oder Premium-Tarif festgelegt sein.

Sie können den Code direkt über Visual Studio in Azure Functions bereitstellen. In dieser Anleitung erfahren Sie, wie Sie Ihren Code über Visual Studio in Azure Functions veröffentlichen.

Alternativen

Für dieses Szenario gibt es verschiedene Alternativen, darunter Pusher. Pusher bietet stabile APIs, mit denen App-Entwickler skalierbare Echtzeit-Kommunikationsfunktionen erstellen können, und ist in diesem Bereich der führende Anbieter.

Eine weitere Alternative ist PubNub. Mit PubNub können Sie Ihren Apps mühelos Echtzeitfunktionen hinzufügen, ohne sich Gedanken über die Infrastruktur machen zu müssen. Erstellen Sie Apps, mit denen Ihre Benutzer auf mobilen Geräten, über Browser, Desktops und Server in Echtzeit kommunizieren können.

Pusher und PubNub sind zweifellos weit verbreitete Plattformen für das Echtzeitmessaging, in diesem Szenario nutzen wir jedoch ausschließlich Azure. SignalR war hier die erste Wahl, da der Dienst die bidirektionale Kommunikation zwischen Server und Client ermöglicht. Zudem ist SignalR ein Open-Source-Tool mit 7.900 GitHub-Sternen und 2.200 GitHub-Forks.

Das Open-Source-Repository für SignalR auf GitHub finden Sie hier.

In diesem Artikel wird erläutert, wie Sie Azure Service Bus-Bindungen in Azure Functions verwenden. Azure Functions unterstützt Trigger und Ausgabebindungen für Service Bus-Warteschlangen und -Themen.

In diesem Artikel wird erläutert, wie Sie SignalR-Bindungen in Azure Functions verwenden, um mit Azure SignalR Service verbundene Clients zu authentifizieren und Nachrichten in Echtzeit an sie zu senden. Azure Functions unterstützt Eingabe- und Ausgabebindungen für den SignalR-Dienst.