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.
Aufbau
Laden Sie eine Visio-Datei dieser Architektur herunter.
Komponenten
- Azure Service Bus ist ein äußerst zuverlässiger Cloudmessagingdienst zwischen Anwendungen und Diensten – auch wenn mehrere davon offline sind.
- Azure SignalR Service ermöglicht auf einfache Weise die Echtzeitkommunikation mit Ihrer Webanwendung.
- Azure Functions ist eine ereignisgesteuerte, serverlose Computeplattform, mit der auch komplexe Orchestrierungsprobleme gelöst werden können.
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.
Ably ist eine weitere Alternative. Es bietet serverloses Veröffentlichen/Abonnieren (pub/sub) Messaging, das zuverlässig mit Ihren Anforderungen skaliert wird. Das Messaging wird am Edge mithilfe von WebSockets übermittelt. Die Ably-Plattform bietet eine hoch verfügbare, elastisch skalierbare und global verteilte Echtzeitinfrastruktur beim Aufruf einer API.
Obgleich Pusher, PubNub und Ably die weit verbreitetsten Plattformen für das Echtzeitmessaging sind, nutzen Sie in diesem Szenario jedoch ausschließlich Azure. Wir empfehlen SignalR als Plattform der Wahl, da sie bidirektionale Kommunikation zwischen Server und Client zulässt. Zudem ist SignalR ein Open-Source-Tool mit 7.900 GitHub-Sternen und 2.200 GitHub-Forks.
Weitere Informationen finden Sie im Open-Source-Repository „SignalR“ auf GitHub.
Szenariodetails
In diesem Szenario richten Sie einen Echtzeit-Messagingdienst zum Teilen des Livestandorts 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.
Sie 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 Chatrooms
Überlegungen
Diese Überlegungen bilden die Säulen des Azure Well-Architected Framework, einer Reihe von Leitprinzipien, die Sie zur Verbesserung der Qualität eines Workloads verwenden können. Weitere Informationen finden Sie unter Microsoft Azure Well-Architected Framework.
Hier finden Sie einige der Überlegungen zur Entwicklung dieses Szenarios, einschließlich der Konfiguration von Parametern in der Azure Service Bus-Verbindungszeichenfolge im ServiceBusTrigger:
- Hubs: Hubs sind mit einem Videostreamingdienst vergleichbar. Sie können einen Hub abonnieren, um Nachrichten an diesen zu senden und von diesem zu empfangen.
- Ziele: Ziele sind wie Radiokanäle. Sie umfassen jeden, der am Zielkanal lauscht, und diese werden benachrichtigt, wenn eine neue Nachricht im Kanal vorhanden ist.
Mit den beiden vorangehenden Features der SignalR-Plattform können Sie die Lösung einfach und schnell in Betrieb nehmen.
Verfügbarkeit, Skalierbarkeit und Sicherheit
Sie können Hochverfügbarkeit mit dieser Lösung erzielen, indem Sie die Anleitungen der folgenden beiden Abschnitte befolgen.
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
Laden Sie eine Visio-Datei dieser Architektur herunter.
Azure Front Door ist ein skalierbarer und sicherer Einstiegspunkt für die schnelle Bereitstellung Ihrer globalen Anwendungen. Wenn Sie prioritätsbasiertes Routing verwenden, führt der Dienst 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. Diesen Schritt müssen Sie manuell durchführen. Bis die DNS-Änderungen weitergegeben wurden, ist die Anwendung nicht verfügbar.
Kostenoptimierung
Bei der Kostenoptimierung geht es um die Suche nach Möglichkeiten, unnötige Ausgaben zu reduzieren und die Betriebseffizienz zu verbessern. Weitere Informationen finden Sie unter Übersicht über die Säule „Kostenoptimierung“.
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 Veröffentlichung 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 | USD 119,40 |
| Azure SignalR Service | USD 48,97 |
| Azure Service Bus | USD 23,71 |
| Gesamt | USD 192,08 |
Bereitstellen dieses Szenarios
Azure Functions-Entwicklung
Eine serverlose Echtzeitanwendung, die mit Azure Functions und Azure SignalR Service erstellt wird, benötigt gewöhnlich zwei Azure-Funktionen:
- Eine
negotiate-Funktion, 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
SignalRFunctionApp
SignalRFunctionApp ist eine Funktions-App, die eine Azure Functions-Instanz mit einem 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. Diese Funktion sollte als negotiate benannt werden. Weitere Informationen finden Sie unter Azure Functions-Entwicklung und -Konfiguration mit Azure SignalR Service.
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
Vorbereitungen
- Stellen Sie sicher, dass Sie eine Service Bus-Warteschlange in Azure bereitgestellt haben.
- Stellen Sie sicher, dass Sie einen SignalR-Dienst im serverlosen Modus in Azure bereitgestellt haben.
- Geben Sie Ihre Verbindungszeichenfolgen (Service Bus und SignalR) in die Datei local.settings.json ein.
- Geben Sie die URL der Clientanwendung (SignalR-Client) in CORS (Cross-Origin Resource Sharing) ein. Die aktuellste Syntax finden Sie unter Azure Functions-Entwicklung und -Konfiguration mit Azure SignalR Service.
- Geben Sie den Namen Ihrer Service Bus-Warteschlange im Service Bus-Trigger in die Datei Message.cs ein.
Nun konfigurieren wir die Clientanwendung, um sie zu testen. Rufen Sie zunächst die Beispielquellen von der GitHub-Seite solution-architectures ab.
SignalR-Client
Dies ist eine einfache .NET Core-Webanwendung, um den Hub zu abonnieren, der von SignalRFunctionApp erstellt wird. Sie zeigt in der Service Bus-Warteschlange empfangene Nachrichten in Echtzeit an. SignalRFunctionApp kann zwar mit einem mobilen Client verwendet werden, für dieses Szenario in diesem Repository bleiben wir jedoch beim Webclient.
Anweisungen
Stellen Sie sicher, dass SignalRFunctionApp ausgeführt wird.
Kopieren Sie die von der negotiate-Funktion generierte URL. Sie sieht etwa wie folgt aus:
http://localhost:7071/api/.Fügen Sie die URL in die Datei chat.js ein, innerhalb von
signalR.HubConnectionBuilder().withUrl("YOUR_URL_HERE").build();.Führen Sie die Anwendung aus.
Der Status ist „Verbunden“, wenn der Webclient den SignalR-Hub erfolgreich abonniert hat.
SendToQueue.js
Dieses Node.js-Skript pusht eine Nachricht an Service Bus, damit Sie die gerade fertig gestellte Bereitstellung testen können.
Instructions
Installieren Sie das Node.js-Modul „Azure Service Bus“ (@azure/service-bus).
Geben Sie Ihre Verbindungszeichenfolgen und den Warteschlangennamen im Skript ein.
Führen Sie das Skript aus.
Nächste Schritte
Sie können dieses Szenario in Ihre Produktionsumgebung übernehmen. Stellen Sie jedoch sicher, dass Ihre Azure-Dienste auf Skalierung festgelegt 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. Informationen zum Veröffentlichen Ihres Codes aus Visual Studio in Azure Functions finden Sie im Leitfaden So erstellen Sie Software.
Informationen zur Verwendung von Azure Service Bus-Bindungen in Azure Functions finden Sie hier. Azure Functions unterstützt Trigger und Ausgabebindungen für Service Bus-Warteschlangen und -Themen.
Informationen zur Verwendung von SignalR Service-Bindungen in Azure Functions, um mit Azure SignalR Service verbundene Clients zu authentifizieren und in Echtzeit Nachrichten an sie zu senden, finden Sie hier. Azure Functions unterstützt Eingabe- und Ausgabebindungen für den SignalR-Dienst.