Tento scénář popisuje, jak navrhovat řešení, které zpracovává změny v podkladových datech v rámci webového zobrazení bez nutnosti aktualizace stránek, a to pomocí služeb v reálném čase. Mezi příklady použití tohoto scénáře patří sledování produktů a zboží v reálném čase a také řešení pro sociální média.
V tomto scénáři se podíváme na to, jak nastavit službu pro zasílání zpráv v reálném čase tak, aby sdílela aktuální polohu transakce služby pro doručování potravin. Tento příklad může být užitečný i pro uživatele, kteří chtějí vytvořit platformu pro sdílení polohy v reálném čase pro své webové nebo mobilní aplikace.
Použijeme službu SignalR nakonfigurovanou v režimu bez serveru k integraci s Azure Functions aplikací aktivované aplikací Service Bus. a to vše pomocí .NET Core.
Potenciální případy použití
Podobné vzory návrhu mají tyto další případy použití:
- Sdílení polohy v reálném čase s klientskými zařízeními
- Nabízení oznámení uživatelům
- Aktualizace časových os
- Vytváření chatovacích místností
Architektura
Komponenty
- Service Bus, vysoce spolehlivá cloudová služba pro zasílání zpráv mezi aplikacemi a službami, i když některé z nich jsou offline.
- SignalR, usnadňující přidání komunikací v reálném čase do vaší webové aplikace.
- Azure Functions, bezserverová výpočetní platforma, která je řízená událostmi a dokáže řešit i složité problémy orchestrace.
Požadavky
Tady jsou některé aspekty, které se zohledňovaly při vývoji tohoto scénáře, včetně postupu při konfiguraci parametrů v připojovacím řetězci služby Azure Service Bus v triggeru ServiceBusTrigger a také:
Centra: Centra se dají přirovnat ke službě streamování videa. V centru se můžete přihlásit k odběru a můžete také odesílat a přijímat zprávy z a do centra.
Cíle: Cíle jsou jako rozhlasové kanály. Každý, kdo poslouchá cílový kanál a dostane upozornění, když je v něm nová zpráva.
Pokud si tyto dvě funkce platformy SignalR zapamatujete, dokážete snadno zajistit rychlé zprovoznění.
Dostupnost, škálovatelnost a zabezpečení
Vysoké dostupnosti tohoto řešení můžete dosáhnout provedením následujících kroků:
Oblastní párování
Každá oblast Azure je spárovaná s jinou oblastí na stejném území. Obecně byste měli volit oblasti ze stejného páru oblastí (například USA – východ 2 a USA – střed). Výhody tohoto postupu jsou následující:
- Pokud dojde k rozsáhlému výpadku, prioritizuje se v každém páru obnovení alespoň jedné oblasti.
- Plánované aktualizace systému Azure se u spárovaných oblastí nasazují postupně, aby se minimalizoval případný výpadek.
- Ve většině případů se oblastní páry nacházejí ve stejné geografické oblasti, aby splňovaly požadavky na rezidenci dat.
- Ujistěte se však, že obě oblasti podporují všechny služby Azure, které vaše aplikace potřebuje. Viz Služby v jednotlivých oblastech. Další informace o oblastních párech najdete v článku Provozní kontinuita a zotavení po havárii (BCDR): Spárované oblasti Azure.
Azure Front Door
Azure Front Door je škálovatelný a zabezpečený vstupní bod pro rychlé doručování globálních aplikací. Pomocí prioritního směrování automaticky převezme služby při selhání, pokud primární oblast přestane být dostupná. Architektura pro více oblastí může poskytnout vyšší dostupnost než nasazení do jedné oblasti. Pokud oblastní výpadek ovlivní primární oblast, můžete pomocí služby Front Door převzít služby při selhání sekundární oblastí. Tato architektura může také pomoct, když selže jednotlivý subsystém řešení. Firewall webových aplikací a DDoS Protection umožňují zastavit útoky na síťovou a aplikační vrstvu na hranici sítě. Posilte vaše služby s využitím sad pravidel spravovaných Microsoftem a vytvářejte si svoje pravidla pro vlastní ochranu vašich aplikací.
Front Door je možným bodem selhání v systému. Pokud služba selže, klienti nebudou mít během výpadku k vaší aplikaci přístup. Zkontrolujte smlouvu o úrovni služeb (SLA) pro Front Door a rozhodněte se, zda použití samotné služby Front Door splňuje vaše podnikové požadavky na vysokou dostupnost. Pokud ne, zvažte přidání jiného řešení správy provozu jako navrácení služeb po obnovení. Pokud služba Front Door selže, změňte záznamy kanonického názvu (CNAME) v DNS tak, aby odkazovaly na jinou službu pro správu provozu. Tento krok je nutné provést ručně a vaše aplikace bude nedostupná, dokud se změny DNS nerozšíří.
Ceny pro tento scénář
Předpokládejme, že firma má 1000 objednávek za den a se všemi z nich musí současně sdílet údaje o poloze. Odhadované využití Azure pro nasazení tohoto scénáře se bude blížit 192 USD za měsíc (na základě cen platných v okamžiku publikování tohoto článku).
| Typ služby | Odhadované měsíční náklady |
|---|---|
| Azure Functions | 119,40 USD |
| Služba Azure SignalR | 48,97 USD |
| Service Bus | 23,71 USD |
| Celkem | 192,08 USD |
Nasazení tohoto scénáře
Vývoj s využitím Azure Functions
Bezserverová aplikace v reálném čase vytvořená a s využitím Azure Functions a Azure SignalR Service zpravidla vyžaduje dvě funkce Azure Functions:
- Funkci „negotiate“, kterou klient volá k získání adresy URL koncového bodu a platného přístupového tokenu služby SignalR Service.
- Jednu nebo několik funkcí, které odesílají zprávy nebo spravují členství ve skupinách.
SignalRFunctionApp
Tato aplikace funkcí vytváří funkci Azure Functions s triggerem služby Service Bus s využitím SignalR.
Negotiate.cs
Tato funkce se aktivuje požadavkem HTTP. Využívají ji klientské aplikace k získání tokenu ze služby SignalR, který klienti mohou využít k přihlášení k odběru z centra. Měla by mít název negotiate. Další informace najdete v tomto průvodci.
Message.cs
Tuto funkci aktivuje trigger služby Service Bus. Má vazbu na službu SignalR. Vytáhne zprávu z fronty a předá ji do centra SignalR.
Pokyny
- Zkontrolujte, že máte v Azure zřízenou frontu Service Bus.
- Zkontrolujte, že máte v Azure zřízenou službu SignalR v bezserverovém režimu.
- Do souboru local.settings.json zadejte připojovací řetězec (Service Bus & SignalR).
- Do CORS zadejte adresu URL klientské aplikace (klient SignalR). Nejnovější syntaxi najdete v tomto průvodci.
- Do triggeru služby Service Bus v souboru Message.cs zadejte název fronty služby Service Bus.
Teď si jako test nakonfigurujeme klientskou aplikaci. Nejdřív si vezměte zdroje příkladů odsud.
Klient SignalR
Jedná se o jednoduchou webovou aplikaci .NET Core, která se přihlašuje k odběru centra vytvořeného aplikací SignalRFunctionApp a zobrazuje zprávy přijaté Service Bus frontě v reálném čase. I když můžete použít SignalRFunctionApp pro práci s mobilním klientem, ale pro účely tohoto úložiště se budeme držet webového klienta.
Pokyny
- Nejprve se ujistěte, že je aplikace SignalRFunctionApp spuštěná.
- Zkopírujte adresu URL vygenerovanou funkcí Negotiate. Bude vypadat přibližně takto:
http://localhost:7071/api/. - Vložte tuto adresu URL do chat.js v
signalR.HubConnectionBuilder().withUrl("YOUR_URL_HERE").build();. - Spusťte aplikaci.
- Pokud se webový klient úspěšně přihlásí k odběru z centra SignalR, zobrazí se stav Připojeno.
SendToQueue.js
Tento skript v node js slouží k nabídnutí zprávy do služby Service Bus, abyste mohli otestovat nasazení, které jste provedli výš.
Pokyny
- Nainstalujte modul Azure Service Bus pro uzly (@azure/service-bus).
- Do skriptu zadejte připojovací řetězce a název fronty.
- Spusťte skript.
Další kroky
Tento scénář můžete přenést do vašeho provozního prostředí, musíte ale zkontrolovat, že máte pro služby Azure nastavené škálování. Například pro službu Azure Service Bus by měl být nastavený plán Standard nebo Premium.
Tento kód můžete do Azure Functions nasadit přímo ze sady Visual Studio. Postupujte podle tohoto průvodce, ve kterém se naučíte, jak publikovat kód do Azure Functions ze sady Visual Studio.
Alternativy
Pro řešení tohoto scénáře existují i další alternativy, včetně Pusheru. Jde o špičkovou sadu robustních rozhraní API určenou pro vývojáře aplikací, kteří vytvářejí škálovatelné funkce pro komunikaci v reálném čase.
K dispozici je také PubNub. PubNub usnadňuje přidávání možností v reálném čase do vašich aplikací, aniž byste si museli dělat starosti o infrastrukturu. Využijte možnost vytvářet aplikace, které vašim uživatelům umožní zapojit se v reálném čase napříč mobilními zařízeními, prohlížeči, desktopy i servery.
Není pochyb, že platformy Pusher a PubNub se pro zasílání zpráv v reálném čase běžně využívají, ale v rámci tohoto scénáře děláme všechno v Azure. Služba SignalR byla mou první volbou, protože umožňuje obousměrnou komunikaci mezi serverem a klientem. Je to také opensourcový nástroj, který má na GitHubu 7,9 tis. hvězdiček a 2,2 tis. forků.
Tady je odkaz na opensourcové úložiště služby SignalR na GitHubu.
Související prostředky
Tento článek vysvětluje, jak ve službě Azure Functions pracovat s vazbami služby Azure Service Bus. Služba Azure Functions podporuje vazby výstupu a triggerů pro témata a fronty služby Service Bus.
Tento článek vysvětluje, jak zajistit ověření a jak klientům připojeným ke službě Azure SignalR Service s využitím vazeb SignalR Service v Azure Functions odesílat zprávy v reálném čase. Služba Azure Functions podporuje vazby vstupu a výstupu pro SignalR Service.