Podstawowe pojęcia dotyczące usługi Azure Web PubSub

Usługa Azure Web PubSub ułatwia tworzenie aplikacji internetowych do obsługi komunikatów w czasie rzeczywistym. Klienci łączą się z usługą przy użyciu standardowego protokołu WebSocket, a usługa uwidacznia interfejsy API REST i zestawy SDK, aby zarządzać tymi klientami.

Terminy

Poniżej przedstawiono kilka ważnych terminów używanych przez usługę:

• Połączenie ion: połączenie, nazywane również klientem lub połączeniem klienta, reprezentuje pojedyncze połączenie protokołu WebSocket połączone z usługą Web PubSub. Po pomyślnym nawiązaniu połączenia unikatowy identyfikator połączenia jest przypisywany do tego połączenia przez usługę Web PubSub.

• Koncentrator: Koncentrator jest logicznym pojęciem dla zestawu połączeń klienckich. Zazwyczaj używasz jednego centrum w jednym scenariuszu, na przykład centrum czatów lub centrum powiadomień . Gdy połączenie klienta nawiązuje połączenie, łączy się z koncentratorem i w okresie jego istnienia należy do tego centrum. Gdy połączenie klienta połączy się z koncentratorem, centrum istnieje. Różne aplikacje mogą udostępniać jedną usługę Azure Web PubSub przy użyciu różnych nazw centrów. Chociaż nie ma ścisłego limitu liczby centrów, centrum zużywa więcej obciążenia usługi w porównaniu z grupą. Zaleca się posiadanie wstępnie określonego zestawu koncentratorów, a nie dynamicznego generowania ich.

• Grupa: grupa jest podzbiorem połączeń z koncentratorem. Możesz dodać połączenie klienta do grupy lub usunąć połączenie klienta z grupy w dowolnym momencie. Na przykład gdy klient dołącza do pokoju rozmów lub gdy klient opuszcza pokój rozmów, ten pokój rozmów może być uważany za grupę. Klient może dołączyć do wielu grup, a grupa może zawierać wielu klientów. Grupa jest jak "sesja", sesja grupy jest tworzona, gdy ktoś dołączy do grupy, a sesja nie zostanie utworzona, gdy nikt nie znajduje się w grupie. Komunikaty wysyłane do grupy są dostarczane do wszystkich klientów połączonych z grupą.

• Użytkownik: Połączenie ions do usługi Web PubSub może należeć do jednego użytkownika. Użytkownik może mieć wiele połączeń, na przykład gdy jeden użytkownik jest połączony z wieloma urządzeniami lub wieloma kartami przeglądarki.

• Komunikat: Po nawiązaniu połączenia klient może wysyłać komunikaty do aplikacji nadrzędnej lub odbierać komunikaty z aplikacji nadrzędnej za pośrednictwem połączenia protokołu WebSocket. Komunikaty mogą być w formacie zwykłego tekstu, binarnego lub JSON i mają maksymalny rozmiar 1 MB.

• Połączenie klienta i Połączenie ionId: klient łączy się z /client punktem końcowym, gdy jest połączony, unikatowy jest generowany przez usługę jako unikatową connectionId tożsamość połączenia klienta. Użytkownicy mogą następnie zarządzać połączeniem klienta przy użyciu tego polecenia connectionId. Szczegóły opisano w sekcji Protokół klienta.

• Zdarzenia klienta: zdarzenia są tworzone podczas cyklu życia połączenia klienta. Na przykład proste połączenie klienta protokołu WebSocket tworzy connect zdarzenie, gdy próbuje nawiązać połączenie z usługą, connected zdarzenie po pomyślnym połączeniu z usługą, message zdarzenie wysyłane do usługi i disconnected zdarzenie, gdy rozłącza się z usługą. Szczegółowe informacje o zdarzeniach klienta przedstawiono w sekcji Protokół klienta.

• Procedura obsługi zdarzeń: program obsługi zdarzeń zawiera logikę do obsługi zdarzeń klienta. Zarejestruj i skonfiguruj programy obsługi zdarzeń w usłudze za pośrednictwem witryny Portal lub interfejsu wiersza polecenia platformy Azure wcześniej. Szczegóły opisano w sekcji Procedura obsługi zdarzeń.

• Odbiornik zdarzeń (wersja zapoznawcza): odbiornik zdarzeń po prostu nasłuchuje zdarzeń klienta, ale nie może zakłócać okresu istnienia klientów przez ich odpowiedź. Szczegóły opisano w sekcji Odbiornik zdarzeń.

• Serwer: serwer może obsługiwać zdarzenia klienta, zarządzać połączeniami klientów lub publikować komunikaty w grupach. Zarówno program obsługi zdarzeń, jak i odbiornik zdarzeń są uważane za po stronie serwera. Szczegółowe informacje o serwerze opisano w sekcji Protokół serwera.

Ważne

HubUserId, Groupsą ważnymi rolami podczas zarządzania klientami i wysyłania komunikatów. Będą one wymagane parametry w różnych wywołaniach interfejsu API REST jako zwykły tekst. Dlatego nie umieszczaj poufnych informacji w tych polach. Na przykład poświadczenia lub tokeny elementu nośnego, które będą miały duże ryzyko wycieku.

Przepływ pracy

Typowy przepływ pracy korzystający z usługi jest pokazany poniżej:

Jak pokazano na powyższym wykresie przepływu pracy:

1. Klient łączy się z punktem końcowym usługi /client przy użyciu transportu protokołu WebSocket. Usługa przekazuje każdą ramkę protokołu WebSocket do skonfigurowanego nadrzędnego (serwera). Połączenie protokołu WebSocket może łączyć się z dowolnym niestandardowym podprotokolem dla serwera do obsługi lub może łączyć się z podprotocolami obsługiwanymi przez usługę (np. json.webpubsub.azure.v1), które umożliwiają klientom bezpośrednie wykonywanie pub/sub. Szczegółowe informacje opisano w protokołach klienta.

2. Usługa wywołuje serwer przy użyciu protokołu CloudEvents w różnych zdarzeniach klienta. CloudEvents to ustandaryzowana i niezależna od protokołu definicja struktury i metadanych zdarzeń hostowanych przez Cloud Native Computing Foundation (CNCF). Szczegóły opisano w protokole serwera.

3. Serwer może wywołać usługę przy użyciu interfejsu API REST, aby wysyłać komunikaty do klientów lub zarządzać połączonymi klientami. Szczegóły opisano w protokole serwera