Wybieranie opcji użycia komunikatów lub zdarzeń

Ukończone

Załóżmy, że planujesz architekturę rozproszonej aplikacji do udostępniania muzyki. Chcesz mieć pewność, że aplikacja będzie tak niezawodna i skalowalna, jak to możliwe, i zamierzasz utworzyć niezawodną infrastrukturę komunikacji, korzystając z technologii platformy Azure.

Zanim wybierzesz odpowiednią technologię platformy Azure, musisz poznać całą komunikację wymienianą przez składniki aplikacji. Dla każdego rodzaju komunikacji możesz wybrać inną technologię platformy Azure.

Pierwszą rzeczą, którą należy ustalić, jest to, czy w ramach komunikacji są wysyłane komunikaty, czy zdarzenia. Ta wiedza pomaga wybrać odpowiednią usługę platformy Azure do użycia.

Strategie komunikacji na platformie Azure (interfejsy API)

Co to jest komunikat?

W terminologii aplikacji rozproszonych komunikaty mają następujące cechy:

  • Komunikat zawiera nieprzetworzone dane generowane przez jeden składnik i używane przez inny składnik.
  • Komunikat zawiera rzeczywiste dane, a nie tylko odwołanie do nich.
  • Składnik wysyłający oczekuje, że składnik docelowy przetworzy zawartość komunikatu w określony sposób. Ogólna integralność systemu może zależeć od nadawcy i odbiorcy wykonującego określone zadanie.

Na przykład załóżmy, że użytkownik przekazuje nowy utwór za pomocą mobilnej aplikacji do udostępniania muzyki. Aplikacja mobilna musi wysłać tę piosenkę do internetowego interfejsu API, który działa na platformie Azure. Musi zostać wysłany rzeczywisty plik multimedialny utworu, a nie jedynie alert wskazujący, że dodano nowy utwór. Aplikacja mobilna oczekuje, że internetowy interfejs API przechowuje nową piosenkę w bazie danych i udostępnia ją innym użytkownikom. To jest przykład komunikatu.

Co to jest zdarzenie?

Zdarzenia są bardziej lekkie niż komunikaty i są najczęściej używane do komunikacji rozgłaszanych. Składniki wysyłające zdarzenia są nazywane wydawcami, a odbierające — subskrybentami.

W przypadku zdarzeń odbieranie składników decyduje o tym, która komunikacja jest im zainteresowana, i "subskrybuj" te zdarzenia. Pośrednik zarządza subskrypcją, na przykład azure Event Grid lub Azure Event Hubs. Gdy wydawcy wysyłają zdarzenie, pośrednik kieruje to zdarzenie do zainteresowanych subskrybentów. Ten wzorzec jest znany jako "architektura publikowania-subskrybowania". Nie jest to jedyny sposób radzenia sobie z wydarzeniami, ale jest to najbardziej powszechne.

Zdarzenia mają następujące cechy:

  • Zdarzenie to uproszczone powiadomienie, które wskazuje, że coś się wydarzyło.
  • Zdarzenie może zostać wysłane do wielu odbiorców albo do żadnego.
  • Zdarzenia są często przeznaczone do szerokiego rozpowszechniania, czyli każdy wydawca ma dużą liczbę subskrybentów.
  • Wydawca zdarzenia nie ma żadnych oczekiwań w stosunku do akcji podejmowanej przez składnik odbierający.
  • Niektóre zdarzenia to odrębne jednostki, które nie są powiązane z innymi zdarzeniami.
  • Inne zdarzenia są częścią powiązanej i uporządkowanej serii.

Załóżmy na przykład, że przekazywanie pliku muzycznego zostało ukończone, a nowy utwór został dodany do bazy danych. Aby poinformować użytkowników o nowym pliku, internetowy interfejs API musi powiadomić o nim użytkowników frontonu internetowego i aplikacji mobilnej. Użytkownicy mogą wybrać, czy słuchać nowej piosenki, więc początkowe powiadomienie nie zawiera pliku muzycznego, ale powiadamia tylko użytkowników, że piosenka istnieje. Nadawca nie ma określonego oczekiwania, że odbiorcy zdarzeń robią wszystko w szczególności w odpowiedzi na to zdarzenie.

Ten scenariusz jest przykładem zdarzenia dyskretnego.

Jak wybrać komunikaty lub zdarzenia

Pojedyncza aplikacja prawdopodobnie będzie używać zdarzeń w niektórych przypadkach i komunikatów w innych. Przed wybraniem należy przeanalizować architekturę aplikacji i wszystkie jej przypadki użycia, aby zidentyfikować wszystkie różne cele, w których jej składniki muszą komunikować się ze sobą.

Zdarzenia są częściej używane w przypadku emisji i są często efemeryczne. Oznacza to, że komunikacja może nie być obsługiwana przez żadnego odbiornika, jeśli żaden z nich nie jest obecnie subskrybowany. Komunikaty będą częściej używane w przypadku, gdy aplikacja rozproszona wymaga gwarancji przetworzenia komunikacji.

Dla każdego rodzaju komunikacji odpowiedz na następujące pytanie: Czy składnik wysyłający oczekuje przetworzenia komunikacji przez składnik docelowy w określony sposób?.

Jeśli odpowiedź brzmi tak, użyj komunikatu. Jeśli odpowiedź brzmi nie, możesz użyć zdarzeń.

Zrozumienie sposobu komunikowania się składników pomaga wybrać sposób komunikowania się składników. Zacznijmy od komunikatów.

Sprawdź swoją wiedzę

1.

Załóżmy, że masz aplikację rozproszoną zawierającą usługę internetową, która uwierzytelnia użytkowników. Gdy użytkownik się loguje, usługa internetowa powiadamia wszystkie aplikacje klienckie, dzięki czemu mogą one wyświetlić stan tego użytkownika jako „Online”. Czy to powiadomienie o zalogowaniu jest przykładem komunikatu, czy zdarzenia?

2.

Załóżmy, że masz aplikację rozproszoną zawierającą usługę internetową, która pozwala użytkownikom na zarządzanie swoimi kontami. Użytkownicy mogą się zarejestrować, edytować swój profil i usunąć swoje konto. Gdy użytkownik usunie swoje konto, usługa internetowa powiadamia warstwę danych, dzięki czemu dane użytkownika zostaną usunięte z bazy danych. Czy to powiadomienie o usunięciu konta jest przykładem komunikatu, czy zdarzenia?