Tento scénář popisuje, jak pomocí služeb v reálném čase vytvořit řešení, které zpracovává změny podkladových dat ve webovém zobrazení bez nutnosti aktualizace stránky. Mezi příklady, které používají tento scénář, patří sledování produktů a zboží v reálném čase a řešení sociálních médií.
Architektura
Stáhněte si soubor aplikace Visio s touto architekturou.
Komponenty
- Azure Service Bus je vysoce spolehlivá cloudová služba zasílání zpráv mezi aplikacemi a službami, i když jsou některé z nich offline.
- Azure SignalR Service usnadňuje přidávání komunikace v reálném čase do webové aplikace.
- Azure Functions je bezserverová výpočetní platforma řízená událostmi, která může také řešit složité problémy orchestrace.
Alternativy
Existují alternativy pro řešení tohoto scénáře, včetně pusheru. Je lídrem v kategorii robustních rozhraní API pro vývojáře aplikací, kteří vytvářejí škálovatelné komunikační funkce v reálném čase.
Je tu taky 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.
Ably je další alternativa. Poskytuje bezserverové zasílání zpráv publikování/odběru (pub/sub), které se spolehlivě škáluje podle vašich potřeb. Zasílání zpráv se doručuje na hraničních zařízeních pomocí protokolu WebSocket. Platforma Ably poskytuje vysoce dostupnou, elasticky škálovatelnou a globálně distribuovanou infrastrukturu v reálném čase při volání rozhraní API.
I když jsou pusher, PubNub a Ably nejrozšířenější platformy pro zasílání zpráv v reálném čase, v tomto scénáři budete dělat všechno v Azure. Jako výchozí platformu doporučujeme SignalR, protože umožňuje obousměrnou komunikaci mezi serverem a klientem. Je to také opensourcový nástroj se 7,9 tisíci hvězdičkami GitHubu a 2,2 tisíci forky GitHubu.
Další informace najdete v opensourcovém úložišti SignalR na GitHubu.
Podrobnosti scénáře
V tomto scénáři se podíváte na to, jak nastavit službu zasílání zpráv v reálném čase tak, aby sdílela živou polohu transakce služby rozvozu jídla. Tento příklad může být užitečný také pro ty, kteří se snaží vytvořit platformu pro sdílení polohy v reálném čase pro své webové nebo mobilní aplikace.
Službu SignalR nakonfigurovanou v bezserverovém režimu použijete k integraci s aplikací Azure Functions, kterou aktivuje služba Service Bus, a to vše pomocí .NET Core.
Potenciální případy použití
Tyto další případy použití mají podobné vzory návrhu:
- 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í
Požadavky
Tyto aspekty implementují pilíře azure Well-Architected Framework, což je sada hlavních zásad, které můžete použít ke zlepšení kvality úloh. Další informace najdete v tématu Microsoft Azure Well-Architected Framework.
Při vývoji tohoto scénáře je potřeba mít na paměti několik věcí, včetně konfigurace parametrů v připojovacím řetězci Azure Service Bus v ServiceBusTriggeru:
- Centra: Rozbočovače je možné přirovnat ke službě streamování videa. Můžete se přihlásit k odběru centra a odesílat a přijímat zprávy z něj a do něj.
- Cíle: Cíle jsou jako rozhlasové kanály. Zahrnují všechny, kdo naslouchají cílovému kanálu, a dostanou oznámení, když se na něm objeví nová zpráva.
Pokud si pamatujete předchozí dvě funkce platformy SignalR, bude snadné rychle začít pracovat.
Dostupnost, škálovatelnost a zabezpečení
Pomocí tohoto řešení můžete dosáhnout vysoké dostupnosti podle toho, co je popsáno v následujících dvou částech.
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, má prioritu obnovení alespoň jedné oblasti z každého páru.
- 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 ale, že obě oblasti podporují všechny služby Azure, které jsou pro vaši aplikaci potřeba. 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
Stáhněte si soubor aplikace Visio s touto architekturou.
Azure Front Door je škálovatelný a zabezpečený vstupní bod pro rychlé doručování globálních aplikací. Pokud použijete prioritní směrování, dojde k automatickému převzetí služeb při selhání, pokud primární oblast přestane být k dispozici. 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ě. Zpevněte svou službu pomocí sad pravidel spravovaných Microsoftem a vytvořte vlastní pravidla pro vlastní ochranu vaší aplikace.
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 přístup k vaší aplikaci. Projděte si smlouvu o úrovni služeb (SLA) služby Front Door a zjistěte, jestli použití samotné služby Front Door splňuje vaše obchodní 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 musíte provést ručně a vaše aplikace bude nedostupná, dokud se změny DNS nerozšířou.
Optimalizace nákladů
Optimalizace nákladů spočívá v hledání způsobů, jak snížit zbytečné náklady a zlepšit provozní efektivitu. Další informace najdete v tématu Přehled pilíře optimalizace nákladů.
Předpokládejme, že vaše firma má denně 1 000 objednávek a potřebuje sdílet data o poloze se všemi z nich současně. Odhadované využití Azure pro nasazení tohoto scénáře se bude blížit 192 USD za měsíc na základě cen k datu publikování.
| Typ služby | Odhadované měsíční náklady |
|---|---|
| Azure Functions | US$119.40 |
| Azure SignalR Service | US$48.97 |
| Azure Service Bus | USD23.71 |
| Celkem | AMERICKÝ DOLAR192.08 |
Nasazení tohoto scénáře
Vývoj s využitím Azure Functions
Bezserverová aplikace v reálném čase, která je sestavená pomocí Azure Functions a Azure SignalR Service, obvykle vyžaduje dvě Azure Functions:
- Funkce
negotiate, kterou klient volá, aby získal platný přístupový token SignalR Service a adresu URL koncového bodu služby. - Jednu nebo několik funkcí, které odesílají zprávy nebo spravují členství ve skupinách.
SignalRFunctionApp
SignalRFunctionApp je aplikace funkcí, která vytvoří instanci Azure Functions s triggerem služby Service Bus s využitím SignalR.
Negotiate.cs
Tato funkce se aktivuje požadavkem HTTP. Používají ho klientské aplikace k získání tokenu ze služby SignalR, který můžou klienti použít k přihlášení k odběru centra. Tato funkce by měla mít název negotiate. Další informace najdete v tématu vývoj a konfigurace Azure Functions pomocí Azure SignalR Service.
Message.cs
Tato funkce se aktivuje triggerem služby Service Bus. Má vazbu na službu SignalR. Vytáhne zprávu z fronty a předá ji do centra SignalR.
Pokyny
Než začnete:
- Ujistěte se, že máte v Azure zřízenou frontu služby Service Bus.
- Ujistěte se, že máte v Azure zřízenou službu SignalR v bezserverovém režimu.
- Do souboru local.settings.json zadejte připojovací řetězce (Service Bus a SignalR).
- Zadejte adresu URL klientské aplikace (klient SignalR) v CORS (Sdílení prostředků mezi zdroji). Nejnovější syntaxi najdete v tématu vývoj a konfigurace Azure Functions pomocí Azure SignalR Service.
- Do triggeru služby Service Bus v souboru Message.cs zadejte název fronty služby Service Bus.
Teď nakonfigurujeme klientskou aplikaci tak, aby ji otestovali. Nejprve si vezměte ukázkové zdroje ze stránky GitHubu architektury řešení .
Klient SignalR
Jedná se o jednoduchou webovou aplikaci .NET Core pro přihlášení k odběru centra vytvořeného aplikací SignalRFunctionApp. Zobrazuje zprávy přijaté ve frontě služby Service Bus v reálném čase. I když můžete signalRFunctionApp použít k práci s mobilním klientem, držme se webového klienta pro tento scénář v tomto úložišti.
Pokyny
Ujistěte se, že je spuštěná aplikace SignalRFunctionApp.
Zkopírujte adresu URL vygenerovanou funkcí negotiate. Vypadá přibližně takto:
http://localhost:7071/api/.Vložte adresu URL do souboruchat.js do
signalR.HubConnectionBuilder().withUrl("YOUR_URL_HERE").build();.Spusťte aplikaci.
Stav je připojen, když se webový klient úspěšně přihlásí k odběru centra SignalR.
SendToQueue.js
Tento skript node.js odešle zprávu do služby Service Bus, abyste mohli otestovat právě dokončené nasazení.
Pokyny
Nainstalujte modul Azure Service Bus node (@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řevést do produkčního prostředí. Ujistěte se však, že služby Azure jsou nastavené na š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. Pokud se chcete dozvědět, jak publikovat kód do Azure Functions ze sady Visual Studio, postupujte podle průvodce Vytváření softwaru.
Podívejte se, jak pracovat s vazbami Azure Service Bus v Azure Functions. Azure Functions podporuje aktivační a výstupní vazby pro fronty a témata služby Service Bus.
Podívejte se, jak ověřovat a odesílat zprávy v reálném čase klientům připojeným k Azure SignalR Service pomocí vazeb SignalR Service v Azure Functions. Služba Azure Functions podporuje vazby vstupu a výstupu pro SignalR Service.