Dela en plats i realtid med hjälp av serverlösa Azure-tjänster utan kostnad

Det här scenariot beskriver hur du skapar en lösning som bearbetar ändringar av underliggande data i en webbvy, utan att behöva en siduppdatering, 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 kommunikationsfunktioner i realtid.

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 serverlösa meddelanden om publicering/prenumeration (pub/sub), som skalar på ett tillförlitligt sätt efter dina behov. Meddelandena levereras vid gränsen med hjälp av WebSockets. Ably-plattformen ger en mycket tillgänglig, elastiskt skalbar och globalt distribuerad realtidsinfrastruktur vid anropet av ett API.

Även om Pusher, PubNub och Ably är de mest antagna plattformarna för realtidsmeddelanden gör du allt i Azure för det här scenariot. Vi rekommenderar SignalR som go-to-plattform eftersom det möjliggör dubbelriktad kommunikation mellan server och klient. Det är också ett verktyg med öppen källkod med 7,9 tusen GitHub-stjärnor och 2,2 tusen GitHub-förgreningar.

Mer information finns i SignalR-lagringsplatsen med öppen källkod på GitHub.

Information om scenario

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 platsdelningsplattform i realtid för sina webb- eller mobilprogram.

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 med hjälp av .NET Core.

Potentiella användningsfall

Dessa andra användningsfall har liknande designmönster:

• Dela realtidsplats med klientenheter
• Skicka meddelanden till användare
• Uppdatera tidslinjer
• Skapa chattrum

Att tänka på

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-niska veze 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). Exempel på fördelar med det:

• 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.
• Kontrollera dock 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 Business continuity and disaster recovery (BCDR): Azure Paired Regions (Affärskontinuitet och haveriberedskap: 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 tjänsten 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öra om användning av Front Door ensam 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 är inte tillgängligt förrän DNS-ändringarna har spridits.

Kostnadsoptimering

Kostnadsoptimering handlar om att titta på sätt att minska onödiga utgifter och förbättra drifteffektiviteten. Mer information finns i Översikt över kostnadsoptimeringspelare.

Anta att ditt företag har 1 000 beställningar per dag och måste dela platsdata med dem 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.

Distribuera det här scenariot

Azure Functions-utveckling

Ett serverlöst realtidsprogram som skapas med Azure Functions och Azure SignalR Service kräver vanligtvis två Azure Functions:

• En negotiate funktion som klienten anropar för att hämta en giltig SignalR Service-åtkomsttoken och tjänstslutpunkts-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 Utveckling och konfiguration av Azure Functions 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.

1. Ange dina niska veze (Service Bus och SignalR) i filen local.settings.json.
2. Ange URL:en för klientprogrammet (SignalR-klienten) i CORS (Resursdelning mellan ursprung). Den senaste syntaxen finns i Utveckling och konfiguration av Azure Functions med Azure SignalR Service.
3. Ange namnet på service bus-kön i Service Bus-utlösaren i filen Message.cs .

Nu ska vi konfigurera klientprogrammet för att testa det. Ta först exempelkällorna från GitHub-sidan för lösningsarkitekturer .

SignalR-klient

Det här är ett enkelt .NET Core-webbprogram för att prenumerera på hubben 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

1. Kontrollera att SignalRFunctionApp körs.

2. Kopiera url:en som genereras av funktionen negotiate. Det ser ut ungefär så här: http://localhost:7071/api/.

3. Klistra in URL:en i filen chat.js i signalR.HubConnectionBuilder().withUrl("YOUR_URL_HERE").build();.

4. Kör programmet.

   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

1. Installera noden Azure Service Bus-modulen (@azure/service-bus).

2. Ange dina anslutningssträngar och könamn i skriptet.

3. 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 till Azure Functions från Visual Studio följer du programguiden It's how you make software(It's how you make software guide).

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.

Relaterade resurser

• Bearbetning av batchtransaktioner med stora volymer
• Överföringshubbens dynamiska pub-sub-meddelandesystem
• Serverlös händelsebearbetning
• Blockkedjearbetsflödesprogram