Een locatie in realtime delen met behulp van goedkope serverloze Azure-services

In dit scenario wordt beschreven hoe u een oplossing ontwerpt waarmee wijzigingen in onderliggende gegevens in een webweergave worden verwerkt, zonder dat een pagina hoeft te worden vernieuwd, met behulp van realtime-services. Voorbeelden die gebruikmaken van dit scenario zijn het realtime bijhouden van producten en goederen en oplossingen voor sociale media.

Architectuur

Een Visio-bestand van deze architectuur downloaden.

Onderdelen

• Azure Service Bus is een zeer betrouwbare cloudberichtenservice tussen toepassingen en services, zelfs wanneer een of meer toepassingen offline zijn.
• Azure SignalR Service maakt het eenvoudig om realtime communicatie toe te voegen aan uw webtoepassing.
• Azure Functions is een gebeurtenisgestuurd, serverloos rekenplatform dat ook complexe indelingsproblemen kan oplossen.

Alternatieven

Er zijn alternatieven om dit scenario aan te pakken, waaronder Pusher. Het is de categorieleider in robuuste API's voor app-ontwikkelaars die schaalbare realtime communicatiefuncties bouwen.

Er is ook PubNub. PubNub maakt het makkelijker om realtime mogelijkheden in te bouwen in uw apps, zonder dat u zich zorgen maakt om de infrastructuur. Bouw apps waarmee uw gebruikers kunnen communiceren via mobiel, browser, desktop en server.

Ably is een ander alternatief. Het biedt serverloze berichten voor publiceren/abonneren (pub/sub), die betrouwbaar wordt geschaald op basis van uw behoeften. De berichten worden geleverd aan de rand met behulp van WebSockets. Het Ably-platform biedt een maximaal beschikbare, elastisch schaalbare en wereldwijd gedistribueerde realtime-infrastructuur, aanroepen van een API.

Hoewel Pusher, PubNub en Ably de meest gebruikte platforms voor realtime berichten zijn, doet u voor dit scenario alles in Azure. We raden SignalR aan als het go-to-platform, omdat hiermee bidirectionele communicatie tussen server en client mogelijk is. Het is ook een opensource-hulpprogramma, met 7,9 duizend GitHub-sterren en 2,2 duizend GitHub-forks.

Zie de opensource-opslagplaats signalR op GitHub voor meer informatie.

Scenariodetails

In dit scenario bekijkt u hoe u een realtime berichtenservice instelt om de livelocatie van een transactie voor de bezorgservice voor etenswaren te delen. Dit voorbeeld kan ook handig zijn voor degenen die een realtime platform voor het delen van locaties willen bouwen voor hun web- of mobiele toepassingen.

U gebruikt een SignalR-service die is geconfigureerd in de serverloze modus om te integreren met een Azure Functions-app die wordt geactiveerd door een servicebus, allemaal met behulp van .NET Core.

Potentiële gebruikscases

Deze andere gebruiksvoorbeelden hebben vergelijkbare ontwerppatronen:

• Realtime-locatie delen met clientapparaten
• Pushmeldingen verzenden naar gebruikers
• Tijdlijnen bijwerken
• Chatruimten maken

Overwegingen

Met deze overwegingen worden de pijlers van het Azure Well-Architected Framework geïmplementeerd. Dit is een set basisprincipes die u kunt gebruiken om de kwaliteit van een workload te verbeteren. Zie Microsoft Azure Well-Architected Framework voor meer informatie.

Hier volgen een aantal dingen waar u rekening mee moet houden bij het ontwikkelen van dit scenario, waaronder het configureren van parameters in de Azure Service Bus connection string in ServiceBusTrigger:

• Hubs: Hubs kunnen worden vergeleken met een videostreamingservice. U kunt zich abonneren op een hub om berichten van en naar deze hub te verzenden en te ontvangen.
• Doelen: Doelen zijn als radiokanalen. Ze omvatten iedereen die naar het doelkanaal luistert en ze krijgen een melding wanneer er een nieuw bericht op staat.

Als u zich de voorgaande twee functies van het SignalR-platform kunt herinneren, kunt u snel aan de slag.

Beschikbaarheid, schaalbaarheid en beveiliging

U kunt hoge beschikbaarheid bereiken met deze oplossing door te volgen wat in de volgende twee secties wordt beschreven.

Regioparen

Elke Azure-regio is gekoppeld aan een andere regio binnen dezelfde geografie. Over het algemeen kiest u regioparen uit dezelfde regio (bijvoorbeeld VS - oost 2 en VS - centraal). Voordelen hiervan zijn:

• Als er een grote storing is, krijgt herstel van ten minste één regio uit elk paar prioriteit.
• Geplande Azure-systeemupdates worden na elkaar uitgerold voor gekoppelde regio's om eventuele downtime tot een minimum te beperken.
• In de meeste gevallen bevinden regioparen zich binnen dezelfde geografie om te voldoen aan gegevenslocatievereisten.
• Zorg er echter voor dat beide regio's alle Azure-services ondersteunen die nodig zijn voor uw toepassing. Raadpleeg Services per regio. Raadpleeg voor meer informatie over regioparen Bedrijfscontinuïteit en herstel na noodgevallen (BCDR): gekoppelde Azure-regio's voor meer informatie.

Azure Front Door

Een Visio-bestand van deze architectuur downloaden.

Azure Front Door is een schaalbaar en beveiligd toegangspunt voor een snelle levering van uw globale toepassingen. Wanneer u prioriteitsroutering gebruikt, wordt er automatisch een failover uitgevoerd als de primaire regio niet meer beschikbaar is. Een architectuur met meerdere regio's kan zorgen voor een hogere beschikbaarheid dan een implementatie in één regio. Als een regionale storing van invloed is op de primaire regio, kunt u met Front Door een failover-schakeling naar de secundaire regio uitvoeren.

Deze architectuur kan ook helpen als een afzonderlijk subsysteem van de oplossing uitvalt. Stop netwerk- en toepassingslaagaanvallen aan de rand met Web Application Firewall en DDoS Protection. Behard uw service met behulp van door Microsoft beheerde regelsets en stel uw eigen regels op voor aangepaste beveiliging van uw app.

Front Door is een mogelijk punt van mislukken in het systeem. Als de service mislukt, hebben clients tijdens de downtime geen toegang tot uw toepassing. Bekijk de Service Level Agreement (SLA) van Front Door en bepaal of het gebruik van Front Door alleen voldoet aan de vereisten van uw bedrijf voor hoge beschikbaarheid. Als dat niet het geval is, overweeg dan een andere oplossing voor het beheer van verkeer toe te voegen als failback. Als de Front Door-service uitvalt, wijzigt u de adresbronrecords (CNAME-records) in DNS zó, dat deze verwijzen naar de andere verkeerbeheerservice. U moet deze stap handmatig uitvoeren en uw toepassing is niet beschikbaar totdat de DNS-wijzigingen worden doorgegeven.

Kostenoptimalisatie

Kostenoptimalisatie gaat over het zoeken naar manieren om onnodige uitgaven te verminderen en de operationele efficiëntie te verbeteren. Zie Overzicht van de pijler kostenoptimalisatie voor meer informatie.

Stel dat uw bedrijf 1.000 bestellingen per dag heeft en locatiegegevens tegelijkertijd met al deze orders moet delen. Uw geschatte Azure-gebruik voor het implementeren van dit scenario ligt in de buurt van USD 192 per maand, op basis van de prijzen op de datum van publicatie.

Dit scenario implementeren

Azure Functions-ontwikkeling

Voor een serverloze realtimetoepassing die is gebouwd met Azure Functions en Azure SignalR Service zijn doorgaans twee Azure Functions vereist:

• Een negotiate functie die door de client wordt aangeroepen om een geldig SignalR Service toegangstoken en service-eindpunt-URL te verkrijgen.
• Een of meer functies die berichten sturen of een groepslidmaatschap beheren.

SignalRFunctionApp

SignalRFunctionApp is een functie-app die een Azure Functions-exemplaar maakt, met een Service Bus-trigger met SignalR.

Negotiate.cs

Dit is een functie die wordt geactiveerd door een HTTP-aanvraag. Het wordt gebruikt door clienttoepassingen om een token op te halen uit de SignalR-service, die clients kunnen gebruiken om zich te abonneren op een hub. Deze functie moet de naam negotiatehebben. Zie Azure Functions ontwikkeling en configuratie met Azure SignalR Service voor meer informatie.

Message.cs

Deze functie wordt geactiveerd door een Service Bus-trigger. Het is gekoppeld aan de signaleringsservice. Het bericht wordt opgehaald uit de wachtrij en doorgestuurd naar een SignalR-hub.

Instructies

Voordat u begint:

• Zorg ervoor dat u een Service Bus-wachtrij hebt ingericht in Azure.
• Zorg ervoor dat u een SignalR-service hebt ingericht in de serverloze modus in Azure.

1. Voer uw verbindingsreeksen (Service Bus en SignalR) in het bestand local.settings.json in.
2. Voer de URL van de clienttoepassing (SignalR-client) in CORS (Cross-Origin Resource Sharing) in. Zie Azure Functions ontwikkeling en configuratie met Azure SignalR Service voor de meest recente syntaxis.
3. Voer de naam van de service bus-wachtrij in de service bus-trigger in het bestand Message.cs in.

Nu gaan we de clienttoepassing configureren om deze te testen. Haal eerst de voorbeeldbronnen op van de GitHub-pagina oplossingsarchitecturen .

SignalR-client

Dit is een eenvoudige .NET Core-webtoepassing om u te abonneren op de hub die is gemaakt door SignalRFunctionApp. Berichten die in de Service Bus-wachtrij zijn ontvangen, worden in realtime weergegeven. Hoewel u SignalRFunctionApp kunt gebruiken om te werken met een mobiele client, houden we het voor dit scenario in deze opslagplaats bij de webclient.

Instructies

1. Zorg ervoor dat SignalRFunctionApp wordt uitgevoerd.

2. Kopieer de URL die wordt gegenereerd door de negotiate-functie. Het ziet er ongeveer als volgt uit: http://localhost:7071/api/.

3. Plak de URL in het chat.js-bestand in signalR.HubConnectionBuilder().withUrl("YOUR_URL_HERE").build();.

4. Voer de toepassing uit.

   De status is verbonden wanneer de webclient zich heeft geabonneerd op de SignalR-hub.

SendToQueue.js

Met dit node.js script wordt een bericht naar Service Bus gepusht, zodat u de implementatie kunt testen die u zojuist hebt voltooid.

Instructies

1. Installeer de module knooppunt Azure Service Bus (@azure/service-bus).

2. Voer de naam van uw verbindingsreeks en wachtrij in het script in.

3. Voer het script uit.

Volgende stappen

U kunt dit scenario meenemen naar uw productieomgeving. Zorg er echter voor dat uw Azure-services zijn ingesteld op schaal. Uw Azure Service Bus moet bijvoorbeeld zijn ingesteld op een standaard of premium abonnement.

U kunt de code vanuit Visual Studio implementeren in Azure Functions. Voor meer informatie over het publiceren van uw code naar Azure Functions vanuit Visual Studio, volgt u de handleiding It's how you make software (Het is hoe u software maakt).

Meer informatie over het werken met Azure Service Bus bindingen in Azure Functions. Azure Functions ondersteunt trigger- en uitvoerbindingen voor Service Bus-wachtrijen en -onderwerpen.

Lees hoe u realtime berichten kunt verifiëren en verzenden naar clients die zijn verbonden met Azure SignalR Service, met behulp van SignalR Service-bindingen in Azure Functions. Azure Functions ondersteunt invoer- en uitvoerbindingen voor SignalR Service.

Gerelateerde resources

• Verwerking van batchtransacties met grote volumes
• Dynamisch pub-subberichtensysteem van transithub
• Serverloze gebeurtenisverwerking
• Toepassing voor blockchainwerkstroom
• Cloudautomatisering op basis van gebeurtenissen