Instrukcje: tworzenie tablicy współpracy w czasie rzeczywistym przy użyciu usługi Azure Web PubSub i wdrażanie jej w Azure App Service

  • Artykuł

Nowa klasa aplikacji zmienia możliwości nowoczesnego działania. Podczas gdy microsoft Word łączy redaktorów, Figma zbiera projektantów w tym samym kreatywnym przedsięwzięciu. Ta klasa aplikacji opiera się na środowisku użytkownika, który sprawia, że czujemy się połączeni z naszymi współpracownikami zdalnymi. Z technicznego punktu widzenia działania użytkownika muszą być synchronizowane na ekranach użytkowników przy małym opóźnieniu.

Omówienie

W tym przewodniku z instrukcjami stosujemy podejście natywne dla chmury i używamy usług platformy Azure do tworzenia tablicy współpracy w czasie rzeczywistym i wdrażamy projekt jako aplikację internetową w celu Azure App Service. Aplikacja tablicy jest dostępna w przeglądarce i umożliwia każdemu rysowanie na tej samej kanwie.

Gif gotowego projektu.

Zapoznaj się z pokazem tablicy na żywo

Architektura

Nazwa usługi platformy Azure Przeznaczenie Korzyści
Azure App Service Udostępnia środowisko hostingu dla aplikacji zaplecza, która jest kompilowana za pomocą platformy Express W pełni zarządzane środowisko zaplecza aplikacji bez konieczności martwienia się o infrastrukturę, w której jest uruchamiany kod
Azure Web PubSub Zapewnia kanał wymiany danych dwukierunkowych z małym opóźnieniem między aplikacją zaplecza a klientami Drastycznie zmniejsza obciążenie serwera przez zwolnienie serwera z zarządzania trwałymi połączeniami protokołu WebSocket i skalowaniem do 100 K współbieżnych połączeń klienckich z tylko jednym zasobem

Diagram architektury aplikacji do współpracy na tablicy.

Wymagania wstępne

Szczegółowe wyjaśnienie przepływu danych można znaleźć na końcu tego przewodnika z instrukcjami, ponieważ najpierw skupimy się na tworzeniu i wdrażaniu aplikacji tablicy.

Aby postępować zgodnie z przewodnikiem krok po kroku, potrzebujesz

Tworzenie zasobów platformy Azure przy użyciu interfejsu wiersza polecenia platformy Azure

1. Zaloguj się

  1. Zaloguj się do interfejsu wiersza polecenia platformy Azure, uruchamiając następujące polecenie.

    az login

  2. Utwórz grupę zasobów na platformie Azure.

    az group create \
  --location "westus" \  
  --name "whiteboard-group"

2. Tworzenie zasobu aplikacji internetowej

  1. Utwórz bezpłatny plan App Service.

    az appservice plan create \ 
  --resource-group "whiteboard-group" \ 
  --name "demo" \ 
  --sku FREE
  --is-linux

  2. Tworzenie zasobu aplikacji internetowej

    az webapp create \
  --resource-group "whiteboard-group" \
  --name "whiteboard-app" \ 
  --plan "demo" \
  --runtime "NODE:18-lts"

3. Tworzenie zasobu Web PubSub

  1. Utwórz zasób Web PubSub.

    az webpubsub create \
  --name "whiteboard-app" \
  --resource-group "whiteboard-group" \
  --location "westus" \
  --sku Free_F1

  2. Pokaż i zapisz wartość gdzieś do późniejszego primaryConnectionString użycia.

    az webpubsub key show \
  --name "whiteboard-app" \
  --resource-group "whiteboard-group"

Pobieranie kodu aplikacji

Uruchom następujące polecenie, aby uzyskać kopię kodu aplikacji. Szczegółowe wyjaśnienie przepływu danych można znaleźć na końcu tego przewodnika z instrukcjami.

git clone https://github.com/Azure/awps-webapp-sample.git

Wdrażanie aplikacji w App Service

  1. App Service obsługuje wiele przepływów pracy wdrażania. W tym przewodniku wdrożymy pakiet ZIP. Uruchom następujące polecenia, aby przygotować plik ZIP.

    npm install
npm run build
zip -r app.zip *

  2. Użyj następującego polecenia, aby wdrożyć go w Azure App Service.

    az webapp deployment source config-zip \
--resource-group "whiteboard-group" \
--name "whiteboard-app" \
--src app.zip

  3. Ustaw parametry połączenia usługi Azure Web PubSub w ustawieniach aplikacji. Użyj wartości przechowywanej primaryConnectionString z wcześniejszego kroku.

    az webapp config appsettings set \
--resource-group "whiteboard-group" \
--name "whiteboard-app" \
--setting Web_PubSub_ConnectionString="<primaryConnectionString>"

Konfigurowanie nadrzędnego serwera w celu obsługi zdarzeń pochodzących z usługi Web PubSub

Za każdym razem, gdy klient wysyła komunikat do usługi Web PubSub, usługa wysyła żądanie HTTP do określonego punktu końcowego. Ten mechanizm jest używany przez serwer zaplecza do dalszego przetwarzania komunikatów, na przykład w przypadku utrwalania komunikatów w wybranej bazie danych.

Podobnie jak w przypadku żądań HTTP, usługa Web PubSub musi wiedzieć, gdzie zlokalizować serwer aplikacji. Ponieważ aplikacja zaplecza jest teraz wdrażana w App Service, otrzymujemy dla niej publicznie dostępną nazwę domeny.

  1. Pokaż i zapisz wartość gdzieś name .

    az webapp config hostname list \
  --resource-group "whiteboard-group"
  --webapp-name "whiteboard-app"

  2. Punkt końcowy, który postanowiliśmy uwidocznić na serwerze zaplecza, to /eventhandler i hub nazwa aplikacji tablicy "sample_draw"

    az webpubsub hub create \ 
  --resource-group "whiteboard-group" \
  --name "whiteboard-app" \
  --hub-name "sample_draw" \
  --event-handler url-template="https://<Replace with the hostname of your Web App resource>/eventhandler" user-event-pattern="*" system-event="connected" system-event="disconnected"

Ważne

url-template ma trzy części: protokół + nazwa hosta + ścieżka, która w naszym przypadku to https://<The hostname of your Web App resource>/eventhandler.

Wyświetlanie aplikacji tablicy w przeglądarce

Teraz przejdź do przeglądarki i przejdź do wdrożonej aplikacji internetowej. Zaleca się otwarcie wielu kart przeglądarki, dzięki czemu można doświadczyć aspektu współpracy w czasie rzeczywistym aplikacji. Możesz też udostępnić link współpracownikowi lub przyjacielowi.

Przepływ danych

Omówienie

Sekcja przepływu danych zawiera szczegółowe informacje na temat sposobu kompilowania aplikacji tablicy. Aplikacja tablicy ma dwie metody transportu.

  • Usługa HTTP napisana jako aplikacja Express i hostowana w App Service.
  • Połączenia WebSocket zarządzane przez usługę Azure Web PubSub.

Za pomocą usługi Azure Web PubSub do zarządzania połączeniami protokołu WebSocket obciążenie aplikacji internetowej jest zmniejszane. Oprócz uwierzytelniania klienta i obsługi obrazów aplikacja internetowa nie jest zaangażowana w synchronizowanie działań rysunkowych. Działania rysunkowe klienta są wysyłane bezpośrednio do usługi Web PubSub i emitowane do wszystkich klientów w grupie.

W dowolnym momencie może istnieć więcej niż jeden rysunek klienta. Jeśli aplikacja internetowa miała zarządzać połączeniami protokołu WebSocket samodzielnie, trzeba było rozgłaszać każde działanie rysunku do wszystkich innych klientów. Ogromny ruch i przetwarzanie są dużym obciążeniem serwera.

Klient utworzony za pomocą programu Vue wysyła żądanie HTTP dla tokenu dostępu klienta do punktu końcowego /negotiate. Aplikacja zaplecza to aplikacja Express i hostowana jako aplikacja internetowa przy użyciu Azure App Service.

Zrzut ekranu przedstawiający krok jeden z przepływu danych aplikacji.

Gdy aplikacja zaplecza pomyślnie zwróci token dostępu klienta do klienta łączącego, klient używa go do ustanowienia połączenia protokołu WebSocket z usługą Azure Web PubSub.

Zrzut ekranu przedstawiający krok drugi przepływu danych aplikacji.

Jeśli uzgadnianie z usługą Azure Web PubSub zakończy się pomyślnie, klient zostanie dodany do grupy o nazwie draw, skutecznie subskrybując komunikaty opublikowane w tej grupie. Ponadto klient otrzymuje uprawnienie do wysyłania komunikatów do draw grupy.

Zrzut ekranu przedstawiający krok trzeci przepływu danych aplikacji.

Uwaga

Aby zachować fokus tego przewodnika, wszystkie łączące się klientów są dodawane do tej samej grupy o nazwie draw i otrzymują uprawnienia do wysyłania komunikatów do tej grupy. Aby zarządzać połączeniami klientów na poziomie szczegółowym, zobacz pełne odwołania do interfejsów API udostępnianych przez usługę Azure Web PubSub.

Usługa Azure Web PubSub powiadamia aplikację zaplecza o połączeniu klienta. Aplikacja zaplecza onConnected obsługuje zdarzenie przez wywołanie sendToAll()elementu , z ładunkiem najnowszej liczby połączonych klientów.

Zrzut ekranu przedstawiający krok czwarty przepływu danych aplikacji.

Uwaga

Należy pamiętać, że jeśli w grupie istnieje duża liczba użytkowników draw online, z jednym wywołaniem sieciowym z aplikacji zaplecza, wszyscy użytkownicy online zostaną powiadomieni, że nowy użytkownik właśnie dołączył. Znacznie zmniejsza to złożoność i obciążenie aplikacji zaplecza.

Gdy klient nawiązuje trwałe połączenie z usługą Web PubSub, wysyła żądanie HTTP do aplikacji zaplecza w celu pobrania najnowszych danych kształtu i tła pod adresem /diagram. Usługę HTTP hostowaną na App Service można połączyć z usługą Web PubSub. App Service dba o obsługę punktów końcowych HTTP, podczas gdy usługa Web PubSub zajmuje się zarządzaniem połączeniami protokołu WebSocket.

Zrzut ekranu przedstawiający krok piąty przepływu danych aplikacji.

Teraz, gdy klienci i aplikacja zaplecza mają dwa sposoby wymiany danych. Jeden jest konwencjonalnym cyklem odpowiedzi żądania HTTP, a drugi jest trwałym, dwukierunkowym kanałem za pośrednictwem usługi Web PubSub. Akcje rysunkowe, które pochodzą z jednego użytkownika i muszą być transmitowane do wszystkich użytkowników, gdy tylko się odbędzie, są dostarczane za pośrednictwem usługi Web PubSub. Nie wymaga zaangażowania aplikacji zaplecza.

Zrzut ekranu przedstawiający sześć kroków przepływu danych aplikacji.

Czyszczenie zasobów

Chociaż aplikacja używa tylko warstw bezpłatnych obu usług, najlepszym rozwiązaniem jest usunięcie zasobów, jeśli nie są już potrzebne. Grupę zasobów można usunąć wraz z zasobami w niej za pomocą następującego polecenia:

az group delete 
  --name "whiteboard-group"

Następne kroki

Zapoznaj się z więcej pokazów utworzonych za pomocą usługi Web PubSub