In dit scenario wordt beschreven hoe u een oplossing verwerkt die wijzigingen verwerkt in onderliggende gegeven binnen een webweergave, zonder dat het nodig is dat de pagina wordt vernieuwd met realtime services. Voorbeelden waarin dit scenario wordt gebruik zijn het realtime volgen van producten en goederen en oplossingen voor sociale media.
In dit scenario kijken we hoe we een realtime berichtenservice opzetten om de live locatie te delen van een bezorgingsdienst. Dit voorbeeld kan ook handig zijn voor gebruikers die een platform willen bouwen om in realtime de locatie te delen voor hun mobiele of webtoepassingen.
We gebruiken een SignalR-service die is geconfigureerd in de servermodus om te integreren met een Azure Functions-app die wordt geactiveerd door een Service Bus; allemaal met behulp van .NET Core.
Potentiële gebruikscases
Deze andere gebruikscases hebben vergelijkbare ontwerppatronen:
- Realtime locatie delen met clientapparaten.
- Meldingen pushen naar gebruikers.
- Tijdlijnen bijwerken.
- Chatruimtes maken.
Architectuur
Onderdelen
- Service Bus, een zeer betrouwbare cloudberichtenservice tussen toepassingen en services, zelfs wanneer er een of meer offline zijn.
- SignalR maakt het makkelijk om realtime communicatie toe te voegen aan uw webtoepassing.
- Azure Functions, een serverloos rekenplatform op basis van gebeurtenissen waarmee u ook complexe indelingsproblemen kunt oplossen.
Overwegingen
Hier volgen een paar overwegingen in dit scenario, inclusief hoe parameters moeten worden geconfigureerd in de Azure Service Bus-verbindingsreeks in de ServiceBusTrigger, evenals:
Hubs: Hubs kunnen worden vergeleken met een videostreamingservice. U kunt zich abonneren op de hub om berichten van/naar de hub te krijgen/sturen.
Doelen: Doelen zijn net als radiokanalen. Iedereen die naar het doelkanaal luistert, wordt op de hoogte gesteld wanneer er een nieuw bericht is.
Als u zich de bovenstaande twee functies van het SignalR-platform herinnert, is het makkelijk om die snel aan de praat te krijgen.
Beschikbaarheid, schaalbaarheid en beveiliging
U bereikt hoge beschikbaarheid in deze oplossing door de volgende twee stappen uit te voeren:
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:
- Bij een grootschalige storing wordt aan ten minste één regio van elk paar prioriteit gegeven.
- 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.
- Controleer wel of alle Azure-services die nodig zijn voor uw toepassing in beide regio's worden ondersteund. 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
Azure Front Door is een schaalbaar en beveiligd toegangspunt voor een snelle levering van uw globale toepassingen. Met prioriteitsroutering wordt automatisch een Failover-overschakeling 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. Bescherm uw service met 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 uitvalt, hebben clients geen toegang tot uw toepassing tijdens de downtime. Controleer de service level agreement (SLA) voor Front Door en bepaal of het gebruik van alleen Front Door voldoet aan uw zakelijke vereisten 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. Deze stap moet handmatig worden uitgevoerd en uw toepassing pas weer beschikbaar als de DNS-wijzigingen zijn doorgegeven.
Prijzen voor dit scenario
Stel dat uw bedrijf 1000 bestellingen per dag verwerkt en voor die bestellingen tegelijkertijd locatiegegevens moet delen, dan is het geschatte Azure-gebruik voor de implementatie van dit scenario rond de $192 per maand, op basis van de prijzen op het moment van schrijven.
| Servicetype | Geschatte maandelijkse kosten |
|---|---|
| Azure Functions | $119,40 |
| Azure SignalR Service | $48,97 |
| Service Bus | $23,71 |
| Totaal | $192,08 |
Dit scenario implementeren
Azure Functions-ontwikkeling
Een serverloze toepassing in realtime die is gebouwd met Azure Functions en Azure SignalR Service heeft over het algemeen twee Azure Functions nodig:
- Een functie 'negotiate' die de client aanroept voor een geldig SignalR Service-toegangstoken en service-eindpunt-URL.
- Een of meer functies die berichten sturen of een groepslidmaatschap beheren.
SignalRFunctionApp
Dit is een functie-app die een Azure-functie maakt met Service Bus-activering 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 van de SignalR Service die clients kunnen gebruiken om zich te abonneren op een hub. De naam moet 'negotiate' zijn. Lees deze handleiding 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
- Zorg ervoor dat u een Service Bus-wachtrij hebt ingericht in Azure.
- Zorg ervoor dat er een SignalR-service hebt ingericht in de serverloze modus op Azure.
- Voer uw verbindingsreeksen (Service Bus en SignalR) in het bestand local.settings.json in.
- Voer de URL van de clienttoepassing (SignalR-client) in CORS in. Deze handleiding biedt de meest recente syntaxis.
- Voer de naam van uw Service Bus-wachtrij in de Service Bus-trigger in binnen het bestand Message.cs.
Nu gaan we de clienttoepassing configureren om te testen. Haal hier eerst de voorbeeldbronnen op
SignalR-client
Dit is een eenvoudige .NET Core-webtoepassing om u te abonneren op de hub die is gemaakt door SignalRFunctionApp en om berichten weer te geven die in realtime zijn ontvangen op Service Bus wachtrij. Hoewel u SignalRFunctionApp kunt gebruiken om met een mobiele client te werken, maar voor deze opslagplaats houden we ons aan de webclient.
Instructies
- Zorg ervoor dat SignalRFunctionApp eerst wordt uitgevoerd.
- Kopieer de URL die wordt gegenereerd door de functie Negotiate. Deze ziet er ongeveer als volgt uit:
http://localhost:7071/api/ - Plak de URL in chat.js in
signalR.HubConnectionBuilder().withUrl("YOUR_URL_HERE").build(); - Voer de toepassing uit.
- U ziet de status verbonden wanneer de webclient zich abonneert op de SignalR-hub.
SendToQueue.js
Dit is een node.js-script om een bericht naar de Service Bus te pushen, zodat u de implementatie zoals hierboven kunt testen.
Instructies
- Installeer de knooppuntmodule van Azure Service Bus (@azure/service-bus).
- Voer de naam van uw verbindingsreeks en wachtrij in het script in.
- Voer het script uit.
Volgende stappen
U kunt dit scenario gebruiken voor uw productieomgeving, maar zorg ervoor dat uw Azure-services zijn geschaald. 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. Volg deze handleiding om te leren hoe u uw code publiceert in Azure Functions vanuit Visual Studio.
Alternatieven
Er bestaan alternatieven voor dit scenario, waaronder Pusher. Dit is de leider voor 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.
Er bestaat geen twijfel over dat Pusher en PubNub veel worden gebruikt voor realtime berichtenservices, maar in dit scenario doen we alles in Azure. SignalR was de te gebruiken service voor mij, omdat het zorgt voor bidirectionele communicatie tussen server en client. Het is ook een opensource-tool met 7,9K GitHub-sterren en 2,2K GitHub-forks.
Hier is een koppeling naar de opensource-opslagplaats van SignalR op GitHub.
Gerelateerde resources
In dit artikel wordt uitgelegd hoe u Azure Service Bus-bindingen in Azure Functions kunt gebruiken. Azure Functions ondersteunt trigger- en uitvoerbindingen voor Service Bus-wachtrijen en -onderwerpen.
In dit artikel wordt uitgelegd hoe u realtime berichten verifieert en stuurt naar clients die zijn verbonden met de Azure SignalR Service met behulp van SignalR Service-bindingen in Azure Functions. Azure Functions ondersteunt invoer- en uitvoerbindingen voor SignalR Service.