Det här scenariot beskriver hur du skapar en lösning som bearbetar ändringar av underliggande data i en webbvy, utan att behöva uppdatera sidan, med hjälp av realtidstjänster. Exempel som använder det här scenariot är spårning i realtid av produkter och varor samt lösningar för sociala medier.
Arkitektur
Ladda ned en Visio-fil med den här arkitekturen.
Komponenter
- Azure Service Bus är en mycket tillförlitlig molnmeddelandetjänst mellan program och tjänster, även när en eller flera är offline.
- Azure SignalR Service gör det enkelt att lägga till realtidskommunikation i webbappen.
- Azure Functions är en händelsedriven, serverlös beräkningsplattform som också kan lösa komplexa orkestreringsproblem.
Alternativ
Det finns alternativ för att hantera det här scenariot, inklusive Pusher. Det är kategoriledaren i robusta API:er för apputvecklare som skapar skalbara funktioner för realtidskommunikation.
Det finns också 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.
Ably är ett annat alternativ. Den tillhandahåller meddelanden om publicering/prenumeration utan server (pub/sub), som kan skalas på ett tillförlitligt sätt efter dina behov. Meddelandena levereras vid gränsen med hjälp av WebSockets. Plattformen Ably ger en elastiskt skalbar och globalt distribuerad realtidsinfrastruktur med hög tillgänglighet vid anropet av ett API.
Även om Pusher, PubNub och Ably är de mest använda plattformarna för meddelanden i realtid gör du allt i Azure i det här scenariot. Vi rekommenderar SignalR som plattform eftersom det möjliggör dubbelriktad kommunikation mellan server och klient. Det är också ett verktyg med öppen källkod med 7,9 000 000 GitHub-stjärnor och 2,2 tusen GitHub-förgreningar.
Mer information finns i SignalR-lagringsplatsen med öppen källkod på GitHub.
Scenarioinformation
I det här scenariot tittar du på hur du konfigurerar en meddelandetjänst i realtid för att dela liveplatsen för en transaktion för matleveranstjänsten. Det här exemplet kan också vara användbart för dem som försöker skapa en plattform för platsdelning i realtid för sina webb- eller mobilappar.
Du 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
Överväganden
Dessa överväganden implementerar grundpelarna i Azure Well-Architected Framework, som är en uppsättning vägledande grundsatser som du kan använda för att förbättra kvaliteten på en arbetsbelastning. Mer information finns i Microsoft Azure Well-Architected Framework.
Här följer några saker att tänka på när du utvecklar det här scenariot, inklusive hur du konfigurerar parametrar i Azure Service Bus anslutningssträngen i ServiceBusTrigger:
- Hubbar: Hubbar kan jämföras med en videoströmningstjänst. Du kan prenumerera på en hubb för att skicka och ta emot meddelanden från och till den.
- Mål: Mål är som radiokanaler. De inkluderar alla som lyssnar på målkanalen och de meddelas när det finns ett nytt meddelande på den.
Om du kommer ihåg de två föregående funktionerna i SignalR-plattformen blir det enkelt att komma igång snabbt.
Tillgänglighet, skalbarhet och säkerhet
Du kan uppnå hög tillgänglighet med den här lösningen genom att följa vad som beskrivs i de kommande två avsnitten.
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 uppstår ett brett avbrott prioriteras återställning av minst en region av 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 regionerna stöder alla Azure-tjänster som behö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
Ladda ned en Visio-fil med den här arkitekturen.
Azure Front Door är en skalbar och säker startpunkt för snabb leverans av dina globala program. När du använder prioritetsroutning redundansväxlar den 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. Härda din tjänst med hjälp av Microsoft-hanterade regeluppsättningar och skapa egna regler för anpassat skydd av din app.
Front Door är en möjlig felpunkt i systemet. Om tjänsten misslyckas kan klienterna inte komma åt ditt program under driftstoppet. Granska serviceavtalet för Front Door (SLA) och avgör om användning av enbart Front Door uppfyller dina affärskrav för 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. Du måste utföra det här steget manuellt och programmet kommer inte att vara tillgängligt förrän DNS-ändringarna har spridits.
Kostnadsoptimering
Kostnadsoptimering handlar om att titta på sätt att minska onödiga kostnader och förbättra driftseffektiviteten. Mer information finns i Översikt över kostnadsoptimeringspelare.
Anta att ditt företag har 1 000 beställningar om dagen och behöver dela platsdata med alla samtidigt. Din uppskattade Azure-användning för att distribuera det här scenariot kommer att vara nära 192 USD per månad, baserat på prissättningen vid publiceringsdatumet.
| Typ av tjänst | Beräknad månadskostnad |
|---|---|
| Azure Functions | USD 119,40 |
| Azure SignalR Service | USD 48,97 |
| Azure Service Bus | USD 23,71 |
| Totalt | USD 192,08 |
Distribuera det här scenariot
Azure Functions-utveckling
Ett serverlöst realtidsprogram som har skapats med Azure Functions och Azure SignalR Service normalt kräver två Azure Functions:
- En
negotiatefunktion som klienten anropar för att hämta en giltig SignalR Service åtkomsttoken och tjänstslutpunktens URL. - En eller flera funktioner som skickar meddelanden eller hanterar gruppmedlemskap.
SignalRFunctionApp
SignalRFunctionApp är en funktionsapp som skapar en Azure Functions-instans med en 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. Den här funktionen ska ha namnet negotiate. Mer information finns i Azure Functions utveckling och konfiguration med Azure SignalR Service,
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
Innan du börjar:
- Kontrollera att du har en Service Bus-kö etablerad i Azure.
- Kontrollera att du har en SignalR-tjänst etablerad i serverlöst läge i Azure.
- Ange anslutningssträngarna (Service Bus och SignalR) i filen local.settings.json .
- Ange URL:en för klientprogrammet (SignalR-klienten) i CORS (Resursdelning för korsande ursprung). Den senaste syntaxen finns i Azure Functions utveckling och konfiguration med Azure SignalR Service.
- Ange service bus-könamnet i Service Bus-utlösaren i filen Message.cs .
Nu ska vi konfigurera klientprogrammet för att testa det. Börja med att hämta exempelkällorna från GitHub-sidan lösningsarkitekturer .
SignalR-klient
Det här är ett enkelt .NET Core-webbprogram som prenumererar på den hubb som skapas av SignalRFunctionApp. Den visar meddelanden som tas emot i Service Bus-kön i realtid. Även om du kan använda SignalRFunctionApp för att arbeta med en mobil klient ska vi hålla oss till webbklienten för det här scenariot på den här lagringsplatsen.
Instruktioner
Kontrollera att SignalRFunctionApp körs.
Kopiera url:en som genereras av negotiate-funktionen. Det ser ut ungefär så här:
http://localhost:7071/api/.Klistra in URL:en i chat.js-filen i
signalR.HubConnectionBuilder().withUrl("YOUR_URL_HERE").build();.Kör appen.
Statusen är ansluten när webbklienten prenumererar på SignalR-hubben.
SendToQueue.js
Det här node.js skriptet skickar ett meddelande till Service Bus så att du kan testa distributionen som du just har slutfört.
Instruktioner
Installera nodmodulen Azure Service Bus (@azure/service-bus).
Ange dina anslutningssträngar och könamn i skriptet.
Kör skriptet.
Nästa steg
Du kan ta det här scenariot till din produktionsmiljö. Kontrollera dock att dina Azure-tjänster är inställda på 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. Om du vill lära dig hur du publicerar din kod för att Azure Functions från Visual Studio följer du guiden Det är så du skapar programvara.
Se 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.
Se 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.