Udostępnianie lokalizacji w czasie rzeczywistym przy użyciu tanich usług platformy Azure bezserwerowych

W tym scenariuszu opisano sposób tworzenia architektury rozwiązania, które przetwarza zmiany w danych bazowych w widoku internetowym bez konieczności odświeżania strony przy użyciu usług w czasie rzeczywistym. Przykłady korzystające z tego scenariusza obejmują śledzenie produktów i towarów w czasie rzeczywistym oraz rozwiązań mediów społecznościowych.

Architektura

Pobierz plik programu Visio z tą architekturą.

Składniki

• Azure Service Bus to wysoce niezawodna usługa obsługi komunikatów w chmurze między aplikacjami i usługami, nawet jeśli co najmniej jedna usługa jest w trybie offline.
• Azure SignalR Service ułatwia dodawanie komunikacji w czasie rzeczywistym do aplikacji internetowej.
• Azure Functions to oparta na zdarzeniach platforma obliczeniowa bezserwerowa, która może również rozwiązywać złożone problemy z orkiestracją.

Alternatywy

Istnieją alternatywy, aby rozwiązać ten scenariusz, w tym pusher. Jest liderem kategorii w niezawodnych interfejsach API dla deweloperów aplikacji, którzy tworzą skalowalne funkcje komunikacji w czasie rzeczywistym.

Jest również PubNub. PubNub ułatwia dodawanie do aplikacji możliwości czasu rzeczywistego bez przejmowania się infrastrukturą. Twórz aplikacje, które umożliwiają użytkownikom angażowanie się w czasie rzeczywistym za pomocą urządzeń przenośnych, przeglądarek, komputerów stacjonarnych i serwerów.

Ably jest inną alternatywą. Zapewnia ona bezserwerowe komunikaty publikowania/subskrybowania (pub/sub), które są skalowane niezawodnie zgodnie z potrzebami. Obsługa komunikatów jest dostarczana na brzegu przy użyciu protokołu WebSockets. Platforma Ably zapewnia wysoce dostępną, elastycznie skalowalną i globalnie rozproszoną infrastrukturę w czasie rzeczywistym przy wywołaniu interfejsu API.

Mimo że pusher, PubNub i Ably to najbardziej powszechnie przyjęte platformy do obsługi komunikatów w czasie rzeczywistym, w tym scenariuszu zrobisz wszystko na platformie Azure. Zalecamy usługę SignalR jako platformę przechodzenia do platformy, ponieważ umożliwia dwukierunkową komunikację między serwerem a klientem. Jest to również narzędzie typu open source z 7,9 tys. gwiazdami usługi GitHub i 2,2 tys. rozwidleniami usługi GitHub.

Aby uzyskać więcej informacji, zobacz repozytorium open source usługi SignalR w witrynie GitHub.

Szczegóły scenariusza

W tym scenariuszu przyjrzysz się, jak skonfigurować usługę obsługi komunikatów w czasie rzeczywistym, aby udostępnić lokalizację na żywo transakcji usługi dostarczania żywności. Ten przykład może być również przydatny dla osób próbujących utworzyć platformę udostępniania lokalizacji w czasie rzeczywistym dla swoich aplikacji internetowych lub mobilnych.

Użyjesz usługi SignalR skonfigurowanej w trybie bezserwerowym, aby zintegrować ją z aplikacją Azure Functions wyzwalaną przez magistralę usług— wszystko to przy użyciu platformy .NET Core.

Potencjalne przypadki użycia

Te inne przypadki użycia mają podobne wzorce projektowe:

• Udostępnianie lokalizacji w czasie rzeczywistym za pomocą urządzeń klienckich
• Wypychanie powiadomień do użytkowników
• Aktualizowanie osi czasu
• Tworzenie pomieszczeń rozmów

Zagadnienia do rozważenia

Te zagadnienia implementują filary platformy Azure Well-Architected Framework, która jest zestawem podstawowych zestawów, których można użyć do poprawy jakości obciążenia. Aby uzyskać więcej informacji, zobacz Microsoft Azure Well-Architected Framework.

Poniżej przedstawiono kilka kwestii, które należy wziąć pod uwagę podczas opracowywania tego scenariusza, w tym sposobu konfigurowania parametrów w parametrach połączenia Azure Service Bus w usłudze ServiceBusTrigger:

• Koncentratory: koncentratory można porównać do usługi przesyłania strumieniowego wideo. Możesz subskrybować centrum, aby wysyłać i odbierać komunikaty z i do niego.
• Cele: Cele są jak kanały radiowe. Obejmują one wszystkich, którzy słuchają kanału docelowego, i są powiadamiani, gdy jest na nim nowa wiadomość.

Jeśli pamiętasz dwie poprzednie funkcje platformy SignalR, łatwo będzie szybko wstać i uruchomić.

Dostępność, skalowalność i bezpieczeństwo

Możesz osiągnąć wysoką dostępność za pomocą tego rozwiązania, postępując zgodnie z opisem w dwóch następnych sekcjach.

Parowanie regionalne

Każdy region platformy Azure jest powiązany z innym regionem w obrębie tego samego obszaru geograficznego. Na ogół regiony wybiera się z tej samej pary regionalnej (na przykład Wschodnie stany USA 2 i Środkowe stany USA). Takie postępowanie przynosi następujące korzyści:

• W przypadku szerokiej awarii odzyskiwanie co najmniej jednego regionu z każdej pary jest priorytetem.
• Planowane aktualizacje systemu platformy Azure są wdrażane w powiązanych regionach po kolei, aby zminimalizować możliwe przestoje.
• W większości przypadków pary regionalne znajdują się w tej samej lokalizacji geograficznej, aby spełnić wymagania dotyczące rezydencji danych.
• Upewnij się jednak, że oba regiony obsługują wszystkie usługi platformy Azure, które są potrzebne dla aplikacji. Zobacz Usługi według regionów. Aby uzyskać więcej informacji na temat par regionalnych, zobacz Business continuity and disaster recovery (BCDR): Azure Paired Regions (Ciągłość działalności biznesowej i odzyskiwanie po awarii — BCDR: regiony sparowane platformy Azure).

Azure Front Door

Pobierz plik programu Visio z tą architekturą.

Usługa Azure Front Door jest skalowalnym i bezpiecznym punktem wejścia do szybkiego dostarczania globalnych aplikacji. Jeśli używasz routingu z priorytetem, automatycznie przełącza się w tryb failover, jeśli region podstawowy stanie się niedostępny. Architektura obejmująca wiele regionów może zapewnić większą dostępność niż wdrożenie w pojedynczym regionie. W przypadku wystąpienia regionalnej awarii, która będzie miała wpływ na region podstawowy, korzystając z usługi Front Door, możesz przejść w trybie failover do regionu pomocniczego.

Ta architektura może również pomóc w przypadku awarii poszczególnych podsystemów rozwiązania. Zatrzymaj ataki w warstwie sieci i aplikacji na urządzeniach brzegowych za pomocą zapory aplikacji internetowej i usługi DDoS Protection. Wzmacnianie funkcjonalności usługi przy użyciu zestawów reguł zarządzanych przez firmę Microsoft i tworzenie własnych reguł w celu niestandardowej ochrony aplikacji.

Usługa Front Door jest punktem systemu, w którym mogą występować awarie. Jeśli usługa zakończy się niepowodzeniem, klienci nie będą mogli uzyskać dostępu do aplikacji podczas przestoju. Zapoznaj się z umową dotyczącą poziomu usług (SLA) usługi Front Door i ustal, czy korzystanie z samej usługi Front Door spełnia wymagania biznesowe dotyczące wysokiej dostępności. Jeśli nie, rozważ dodanie kolejnego rozwiązania do zarządzania ruchem w ramach powrotu po awarii. W przypadku awarii usługi Front Door zmień rekordy nazwy kanonicznej (CNAME) w systemie DNS, aby wskazać inną usługę zarządzania ruchem. Ten krok należy wykonać ręcznie, a aplikacja będzie niedostępna do momentu propagacji zmian DNS.

Optymalizacja kosztów

Optymalizacja kosztów dotyczy sposobów zmniejszenia niepotrzebnych wydatków i poprawy wydajności operacyjnej. Aby uzyskać więcej informacji, zobacz Omówienie filaru optymalizacji kosztów.

Załóżmy, że Twoja firma ma 1000 zamówień dziennie i musi udostępniać dane lokalizacji wszystkim z nich jednocześnie. Szacowane użycie platformy Azure do wdrożenia tego scenariusza będzie zbliżone do 192 USD miesięcznie na podstawie cen w dniu publikacji.

Wdrażanie tego scenariusza

Opracowywanie usługi Azure Functions

Aplikacja bezserwerowa utworzona przy użyciu Azure Functions i Azure SignalR Service zwykle wymaga dwóch Azure Functions:

• negotiate Funkcja wywoływana przez klienta w celu uzyskania prawidłowego SignalR Service tokenu dostępu i adresu URL punktu końcowego usługi.
• Co najmniej jedna funkcja, która wysyła komunikaty lub zarządza członkostwem w grupie.

SignalRFunctionApp

SignalRFunctionApp to aplikacja funkcji, która tworzy wystąpienie Azure Functions z wyzwalaczem usługi Service Bus z usługą SignalR.

Negotiate.cs

Ta funkcja jest wyzwalana przez żądanie HTTP. Jest on używany przez aplikacje klienckie do uzyskiwania tokenu z usługi SignalR, której klienci mogą używać do subskrybowania koncentratora. Ta funkcja powinna mieć nazwę negotiate. Aby uzyskać więcej informacji, zobacz Azure Functions programowanie i konfigurowanie przy użyciu Azure SignalR Service,

Message.cs

Ta funkcja jest wyzwalana przez wyzwalacz usługi Service Bus. Ma ona powiązanie z usługą SignalR. Ta funkcja pobiera komunikat z kolejki i przekazuje go do centrum SignalR.

Instrukcje

Przed rozpoczęciem:

• Upewnij się, że masz kolejkę usługi Service Bus aprowizowaną na platformie Azure.
• Upewnij się, że masz usługę SignalR aprowizowaną w trybie bezserwerowym na platformie Azure.

1. Wprowadź parametry połączenia (Service Bus i SignalR) w pliku local.settings.json .
2. Wprowadź adres URL aplikacji klienckiej (klienta SignalR) w mechanizmie CORS (współużytkowanie zasobów między źródłami). Aby uzyskać najnowszą składnię, zobacz Azure Functions programowanie i konfigurowanie przy użyciu Azure SignalR Service.
3. Wprowadź nazwę kolejki usługi Service Bus w wyzwalaczu usługi Service Bus w pliku Message.cs .

Teraz skonfigurujmy aplikację kliencą, aby ją przetestować. Najpierw pobierz przykładowe źródła ze strony usługi GitHub solution-architectures .

Klient SignalR

Jest to prosta aplikacja internetowa platformy .NET Core, która subskrybuje centrum utworzone przez aplikację SignalRFunctionApp. Wyświetla komunikaty odbierane w kolejce usługi Service Bus w czasie rzeczywistym. Mimo że możesz użyć aplikacji SignalRFunctionApp do pracy z klientem mobilnym, trzymajmy się klienta internetowego w tym scenariuszu w tym repozytorium.

Instrukcje

1. Upewnij się, że aplikacja SignalRFunctionApp jest uruchomiona.

2. Skopiuj adres URL wygenerowany przez funkcję negotiate. Wygląda to następująco: http://localhost:7071/api/.

3. Wklej adres URL w pliku chat.js w pliku signalR.HubConnectionBuilder().withUrl("YOUR_URL_HERE").build();.

4. Uruchom aplikację.

   Stan jest połączony, gdy klient internetowy pomyślnie subskrybuje centrum SignalR.

SendToQueue.js

Ten skrypt node.js wypycha komunikat do usługi Service Bus, aby można było przetestować właśnie ukończone wdrożenie.

Instrukcje

1. Zainstaluj moduł Azure Service Bus węzła (@azure/service-bus).

2. W skrypcie wprowadź parametry połączenia i nazwę kolejki.

3. Uruchom skrypt.

Następne kroki

Ten scenariusz można podjąć w środowisku produkcyjnym. Upewnij się jednak, że usługi platformy Azure są ustawione na skalowanie. Na przykład dla usługi Azure Service Bus powinien być ustawiony plan standardowy lub Premium.

Kod można wdrożyć w usłudze Azure Functions bezpośrednio z programu Visual Studio. Aby dowiedzieć się, jak opublikować kod w celu Azure Functions z poziomu programu Visual Studio, postępuj zgodnie z instrukcjami dotyczącymi tworzenia oprogramowania.

Zobacz, jak pracować z powiązaniami Azure Service Bus w Azure Functions. Azure Functions obsługuje powiązania wyzwalacza i wyjściowe dla kolejek i tematów usługi Service Bus.

Zobacz, jak uwierzytelniać i wysyłać komunikaty w czasie rzeczywistym do klientów połączonych z Azure SignalR Service przy użyciu powiązań SignalR Service w Azure Functions. Usługa Azure Functions obsługuje powiązania wejściowe i wyjściowe dla usługi SignalR Service.

Powiązane zasoby

• Przetwarzanie transakcji wsadowych o dużej ilości
• Dynamiczny system obsługi komunikatów pub-sub centrum tranzytowego
• Bezserwerowe przetwarzanie zdarzeń
• Aplikacja przepływu pracy bazująca na łańcuchu bloków
• Automatyzacja w chmurze oparta na zdarzeniach