Wybierz, czy używać komunikatów, czy zdarzeń
Załóżmy, że planujesz architekturę rozproszonej aplikacji do udostępniania muzyki. Chcesz mieć pewność, że aplikacja jest tak niezawodna i skalowalna, jak to możliwe, i zamierzasz używać technologii platformy Azure do tworzenia niezawodnej infrastruktury komunikacyjnej.
Zanim będzie można wybrać odpowiednią technologię platformy Azure, musisz zrozumieć każdą komunikację poszczególnych składników wymiany aplikacji. Dla każdej komunikacji można wybrać inną technologię platformy Azure.
Pierwszą rzeczą, którą trzeba zrozumieć na temat komunikacji, jest to, czy wysyła wiadomości, czy wydarzenia. 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 same dane, a nie tylko odwołanie do tych danych.
- 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.
Załóżmy na przykład, że użytkownik przekazuje nową piosenkę przy użyciu mobilnej aplikacji do udostępniania muzyki. Aplikacja mobilna musi wysłać tę piosenkę do internetowego interfejsu API, który działa na platformie Azure. Sam plik multimedialny piosenki musi zostać wysłany, a nie tylko alert wskazujący, że dodano nową piosenkę. Aplikacja mobilna oczekuje, że internetowy interfejs API przechowuje nową piosenkę w bazie danych i udostępnia ją innym użytkownikom. Jest to przykład komunikatu.
Co to jest zdarzenie?
Zdarzenia są lżejsze niż wiadomości i są najczęściej wykorzystywane do komunikacji rozgłoszeniowej. Składniki wysyłające zdarzenie są znane jako wydawcy , a odbiorcy są znani jako subskrybenci .
W przypadku zdarzeń komponenty odbiorcze decydują, którą komunikacją są zainteresowane, a następnie 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 jest lekkim powiadomieniem wskazującym, że coś się stało.
- Zdarzenie może być wysyłane do wielu odbiorników lub do żadnego w ogóle.
- Zdarzenia są często projektowane tak, aby się "rozprzestrzeniać", to znaczy mieć dużą liczbę subskrybentów dla każdego wydawcy.
- Wydawca zdarzenia nie ma oczekiwań co do działań podejmowanych przez składnik odbierający.
- Niektóre zdarzenia to odrębne jednostki i niepowiązane z innymi zdarzeniami.
- Niektóre 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 zostanie dodany do bazy danych. Aby poinformować użytkowników o nowym pliku, internetowy interfejs API musi poinformować użytkowników frontonu internetowego i aplikacji mobilnej o nowym pliku. 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ń podejmują jakiekolwiek szczególne działania w odpowiedzi na to zdarzenie.
Ten scenariusz jest przykładem dyskretnego zdarzenia.
Jak wybrać komunikaty lub zdarzenia
Jest prawdopodobne, że jedna aplikacja użyje zdarzeń do niektórych celów i komunikatów do 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ą bardziej skłonne do bycia używanymi do transmisji i są często krótkotrwałe, co oznacza, że komunikacja nie jest obsługiwana przez żadnego odbiornika, jeśli nikt ich obecnie nie subskrybuje. Wiadomości są częściej używane w sytuacjach, gdy aplikacja rozproszona wymaga gwarancji, że komunikacja zostanie przetworzona.
Dla każdej komunikacji należy rozważyć następujące pytanie: Czy składnik wysyłający oczekuje, że komunikacja zostanie przetworzona w określony sposób przez składnik docelowy?
Jeśli odpowiedź brzmi tak, wybierz opcję użycia komunikatu. Jeśli odpowiedź jest nie, można spróbować użyć wydarzeń.
Zrozumienie, jak muszą się porozumiewać twoje składniki, pomaga wybrać najlepszy sposób ich komunikacji. Zacznijmy od komunikatów.