I det här scenariot beskrivs hur du utformar en lösning som bearbetar ändringar av underliggande data i en webbvy utan behov av en siduppdatering via realtidstjänster. Exempel som använder det här scenariot är spårning av produkter och varor i realtid samt lösningar för sociala medier.
I det här scenariot tittar vi på hur du konfigurerar en meddelandetjänst med realtidsfunktion för att dela live-plats för en transaktion som sker via en matleveranstjänst. Det här exemplet kan även vara användbart för användare som försöker bygga en plattform för platsdelning i realtid för sina webb- eller mobilappar.
Vi använder en SignalR-tjänst som konfigurerats i serverlöst läge för att integrera med en Azure Functions-app som utlöses av en Service Bus, allt detta med hjälp av .NET Core.
Potentiella användningsfall
Dessa andra användningsfall har liknande designmönster:
- Dela realtidsplats med klientenheter.
- Skicka push-meddelanden till användare.
- Uppdatera tidslinjer.
- Skapa chattrum.
Arkitektur
Komponenter
- Service Bus, en tillförlitlig molnbaserad meddelandetjänst för kommunikation mellan program och tjänster som fungerar även när en eller flera är offline.
- SignalR gör det enkelt att lägga till realtidskommunikation i webbappar.
- Azure Functions, en händelsedriven, serverlös beräkningsplattform som även kan lösa komplexa orkestreringsproblem.
Överväganden
Här är några av de överväganden som du vidtar för att utveckla det här scenariot, däribland hur du konfigurerar parametrar i Azure Service Bus-anslutningssträngen i ServiceBusTrigger samt:
Hubbar: Hubbar kan jämföras med en videoströmningstjänst. Du kan prenumerera på hubben för att skicka/ta emot meddelanden från/till hubben.
Mål: Mål fungerar som radiokanaler. Alla som lyssnar på målkanalen meddelas när det finns ett nytt meddelande på den.
Om du håller ovanstående två egenskaper i åtanke vad gäller SignalR-plattformen blir det enkelt att komma igång snabbt.
Tillgänglighet, skalbarhet och säkerhet
Du kan uppnå hög tillgänglighet för den här lösningen genom att utföra följande steg:
Regional länkning
Varje Azure-region är kopplad till en annan region inom samma geografiska område. I allmänhet väljer du regioner från samma regionala par (till exempel USA, östra 2 och USA, centrala). Detta ger följande fördelar:
- Om det sker ett stort avbrott prioriteras återställning av minst en region i varje par.
- Planerade uppdateringar av Azure-systemet utförs sekventiellt i hopparade regioner för att minimera eventuella driftstopp.
- I de flesta länder är regionala par belägna inom samma geografiska område för att uppfylla kraven på datahemvist.
- Se dock till att båda regioner har stöd för alla Azure-tjänster som krävs för ditt program. Se Tjänster per region. Mer information om regionala par finns i Affärskontinuitet och haveriberedskap (BCDR): Länkade Azure-regioner.
Azure Front Door
Azure Front Door är en skalbar och säker startpunkt för snabb leverans av dina globala program. Med hjälp av prioriterad routning redundansväxlar det automatiskt om den primära regionen blir otillgänglig. En arkitektur med flera regioner kan ge högre tillgänglighet än att distribuera till en enskild region. Om ett regionalt avbrott påverkar den primära regionen kan du använda Front Door för att redundansväxla till den sekundära regionen. Den här arkitekturen kan även hjälpa om ett enskilt undersystem i lösningen slutar fungera. Stoppa nätverks- och programlagerattacker på gränsen med brandvägg för webbaserade program och DDoS Protection. Skydda tjänsten med hjälp av Microsoft-hanterade regeluppsättningar och skapa egna regler för anpassat skydd av appen.
Front Door är en möjlig felpunkt i systemet. Om det uppstår fel i tjänsten kan klienterna inte komma åt ditt program under driftstoppet. Läs serviceavtalet för Front Door och avgör huruvida användning av enbart Front Door uppfyller företagets krav på hög tillgänglighet. Om det inte räcker bör du överväga att lägga till ytterligare en trafikhanteringslösning som extra skydd. Om Front Door-tjänsten slutar fungera ändrar du posterna för kanoniska namn (CNAME) i DNS så att de pekar mot den andra trafikhanteringstjänsten. Det här steget måste utföras manuellt och programmet förblir otillgängligt tills DNS-ändringarna har spridits.
Prissättning för det här scenariot
Anta att ditt företag får 1 000 beställningar på en dag och behöver dela platsdata med alla dessa samtidigt. Din uppskattade Azure-användning för distribution av detta scenario blir nära 192 USD per månad baserat på aktuell prissättning när detta skrevs.
| Typ av tjänst | Uppskattad månatlig kostnad |
|---|---|
| Azure Functions | 119,40 USD |
| Azure SignalR Service | 48,97 USD |
| Service Bus | 23,71 USD |
| Totalt | 192,08 USD |
Distribuera det här scenariot
Azure Functions-utveckling
Ett serverlöst realtidsprogram som skapats med Azure Functions och Azure SignalR-tjänsten kräver vanligtvis två Azure Functions:
- En ”negotiate-funktion” som klienten anropar för att hämta en giltig SignalR Service-åtkomsttoken och en URL till en tjänstslutpunkt.
- En eller flera funktioner som skickar meddelanden eller hanterar gruppmedlemskap.
SignalRFunctionApp
Det här är en funktionsapp som skapar en Azure-funktion med Service Bus-utlösare med SignalR.
Negotiate.cs
Den här funktionen utlöses av en HTTP-begäran. Den används av klientprogram för att hämta en token från SignalR-tjänsten som klienter kan använda för att prenumerera på en hubb. Detta bör få namnet "negotiate". Mer information finns i den här guiden
Message.cs
Den här funktionen utlöses av en Service Bus-utlösare. Den har en bindning med SignalR-tjänsten. Den hämtar meddelandet från kön och skickar det vidare till en SignalR-hubb.
Instruktioner
- Se till att du har en Service Bus-kö etablerad i Azure.
- Se till att du har en SignalR-tjänst etablerad i serverlöst läge i Azure.
- Ange anslutningssträngarna (Service Bus & SignalR) i &
- Ange URL:en för klientprogram (SignalR-klienten) i CORS. Den här guiden innehåller den senaste syntaxen.
- Ange ditt Service Bus-könamn i Service Bus-utlösaren i filen Message.cs.
Nu ska vi testa genom att konfigurera klientprogrammet. Börja med att hämta exempelkällorna här
SignalR-klient
Det här är en enkel .NET Core-webbapp som prenumererar på hubben som skapats av SignalRFunctionApp och visar meddelanden som tas emot Service Bus kön i realtid. Även om du kan använda SignalRFunctionApp för att arbeta med en mobil klient, men för den här lagringsplatsen håller vi oss till webbklienten.
Instruktioner
- Kontrollera att SignalRFunctionApp körs först.
- Kopiera den URL som genereras av Negotiate-funktionen. Den ser ut ungefär så här:
http://localhost:7071/api/ - Klistra in webbadressen till chat.js i
signalR.HubConnectionBuilder().withUrl("YOUR_URL_HERE").build(); - Kör appen.
- Du ser ansluten status när webbklienten prenumererar på SignalR-hubben.
SendToQueue.js
Det här är ett node.js-skript för att skicka ett meddelande till Service Bus så att du kan testa den distribution som du gjorde ovan.
Instruktioner
- Installera noden Azure Service Bus-modul (@azure/service-bus).
- Ange dina anslutningssträngar och könamn i skriptet.
- Kör skriptet.
Nästa steg
Du kan ta med det här scenariot till din produktionsmiljö, men se till att dina Azure-tjänster har konfigurerats för skalning. Till exempel bör din Azure Service Bus vara inställt på en Standard- eller Premium-plan.
Du kan distribuera koden till Azure Functions direkt från Visual Studio. Följ den här guiden om du vill lära dig hur du publicerar kod till Azure Functions från Visual Studio.
Alternativ
Det finns alternativ för att behandla det här scenariot, däribland Pusher. Detta är ledaren i sin kategori för robusta API:er som apputvecklare kan använda för att bygga skalbara funktioner för realtidskommunikation.
Dessutom finns PubNub. Med PubNub kan du enkelt lägga till realtidsfunktioner i appar utan att behöva oroa dig för infrastrukturen. Bygg appar som gör det möjligt för dina användare att delta i realtid via mobila enheter, webbläsare, stationära datorer och servrar.
Pusher och PubNub är definitivt de mest använda plattformarna för realtidsmeddelanden, men i just det här scenariot utför vi allt i Azure. Jag valde SignalR eftersom det tillåter dubbelriktad kommunikation mellan server och klient. Det är även ett verktyg med öppen källkod som har 7 900 GitHub-stjärnor och 2 200 GitHub-förgreningar.
Här en länk till lagringsplatsen för SignalR med öppen källkod på GitHub.
Relaterade resurser
I den här artikeln beskrivs hur du arbetar med Azure Service Bus-bindningar i Azure Functions. Azure Functions stöder utlösar- och utdatabindningar för Service Bus-köer och -ämnen.
I den här artikeln beskrivs hur du autentiserar och skickar realtidsmeddelanden till klienter som är anslutna till Azure SignalR Service med hjälp av SignalR Service-bindningar i Azure Functions. Azure Functions stöder indata- och utdatabindningar för SignalR Service.