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 danych bazowych w widoku internetowym bez konieczności odświeżania strony przy użyciu usług czasu rzeczywistego. Przykłady, które korzystają 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

• Usługa 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.
• Usługa 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

Alternatywy istnieją, aby rozwiązać ten scenariusz, w tym pusher. Jest to lider 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 kolejną alternatywą. Zapewnia ona bezserwerową obsługę komunikatów publikowania/subskrybowania (pub/sub), która jest niezawodnie skalowana zgodnie z potrzebami. Obsługa komunikatów jest dostarczana na brzegu przy użyciu obiektów WebSocket. Platforma Ably zapewnia wysoce dostępną, elastycznie skalowalną i globalnie rozproszoną infrastrukturę czasu rzeczywistego przy wywołaniu interfejsu API.

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

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

Szczegóły scenariusza

W tym scenariuszu dowiesz się, jak skonfigurować usługę obsługi komunikatów w czasie rzeczywistym, aby udostępnić na żywo lokalizację 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ą usługi Azure Functions wyzwalaną przez magistralę usług, a wszystko to za pomocą platformy .NET Core.

Potencjalne przypadki użycia

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

• Udostępnianie lokalizacji w czasie rzeczywistym z urządzeniami klienckimi
• Wypychanie powiadomień do użytkowników
• Aktualizowanie osi czasu
• Tworzenie pokoi rozmów

Kwestie wymagające rozważenia

Te zagadnienia implementują filary platformy Azure Well-Architected Framework, która jest zestawem wytycznych, 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 usłudze Azure Service Bus parametry połączenia w usłudze ServiceBusTrigger:

• Koncentratory: koncentratory można porównać z usługą przesyłania strumieniowego wideo. Możesz subskrybować centrum w celu wysyłania i odbierania komunikatów z i do niego.
• Cele: Cele są podobne do kanałów radiowych. 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

Dzięki temu rozwiązaniu można uzyskać wysoką dostępność, postępując zgodnie z opisem w kolejnych dwóch 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:

• Jeśli wystąpi szeroka awaria, 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. W przypadku korzystania z routingu o priorytecie automatycznie przełączy 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 zabezpieczeń usługi przy użyciu zestawów reguł zarządzanych przez firmę Microsoft i tworzenie własnych reguł w celu zapewnienia niestandardowej ochrony aplikacji.

Usługa Front Door jest punktem systemu, w którym mogą występować awarie. Jeśli usługa ulegnie awarii, 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 propagowania 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 na potrzeby wdrażania 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

Bezserwerowa aplikacja w czasie rzeczywistym utworzona za pomocą usług Azure Functions i Azure SignalR Service zwykle wymaga dwóch funkcji platformy Azure:

• Funkcja wywoływana negotiate przez klienta w celu uzyskania prawidłowego tokenu dostępu usługi SignalR Service 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 usługi Azure Functions z wyzwalaczem usługi Service Bus z usługą SignalR.

Negotiate.cs

Ta funkcja jest wyzwalana przez żądanie HTTP. Jest ona używana przez aplikacje klienckie do uzyskiwania tokenu z usługi SignalR, którego klienci mogą używać do subskrybowania koncentratora. Ta funkcja powinna mieć nazwę negotiate. Aby uzyskać więcej informacji, zobacz Azure Functions development and configuration with Azure SignalR Service (Programowanie i konfigurowanie usługi Azure Functions za pomocą usługi 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 development and configuration with Azure SignalR Service (Programowanie i konfigurowanie usługi Azure Functions za pomocą usługi Azure SignalR Service).
3. Wprowadź nazwę kolejki usługi Service Bus w wyzwalaczu usługi Service Bus w pliku Message.cs .

Teraz skonfigurujemy aplikację kliencą, aby ją przetestować. Najpierw pobierz przykładowe źródła ze strony GitHub architektury rozwiązań.

Klient SignalR

Jest to prosta aplikacja internetowa platformy .NET Core do subskrybowania centrum utworzonego przez aplikację SignalRFunctionApp. Wyświetla komunikaty odbierane w kolejce usługi Service Bus w czasie rzeczywistym. Mimo że można użyć aplikacji SignalRFunctionApp do pracy z klientem mobilnym, trzymajmy się klienta internetowego dla tego scenariusza w tym repozytorium.

Instrukcje

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

2. Skopiuj adres URL wygenerowany przez funkcję negotiate. Wygląda to mniej więcej tak: 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 (@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 usłudze Azure Functions z poziomu programu Visual Studio, postępuj zgodnie z instrukcjami tworzenia oprogramowania .

Zobacz , jak pracować z powiązaniami usługi Azure Service Bus w usłudze Azure Functions. Usługa Azure Functions obsługuje powiązania wyzwalacza i danych wyjściowych 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 usługą Azure SignalR Service przy użyciu powiązań usługi SignalR Service w usłudze 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
• Przetwarzanie zdarzeń bezserwerowych
• Aplikacja przepływu pracy łańcucha bloków