Wybieranie dostarczania z użyciem kolejek zawierających komunikaty

  • 8 min

Załóżmy, że planujesz architekturę aplikacji do udostępniania muzyki. Chcesz mieć pewność, że pliki muzyczne są niezawodnie przekazywane do internetowego interfejsu API z aplikacji mobilnej. Chcesz też, by szczegółowe informacje o nowych utworach były dodawane bezpośrednio do aplikacji, gdy tylko wykonawca doda nową muzykę do swojej kolekcji. Ten scenariusz jest idealnym zastosowaniem systemu opartego na komunikatach, a platforma Azure oferuje dwa rozwiązania tego problemu:

  • Azure Queue Storage
  • Azure Service Bus

Co to jest Azure Queue Storage?

Queue Storage to usługa używająca usługi Azure Storage do przechowywania dużej liczby komunikatów, do których można bezpiecznie uzyskiwać dostęp z dowolnego miejsca na świecie za pomocą prostego interfejsu opartego na protokole REST. Kolejki mogą zawierać miliony komunikatów, jedynym ograniczeniem jest pojemność konta magazynu, które jest ich właścicielem.

Co to są kolejki usługi Azure Service Bus?

Service Bus to system brokera komunikatów przeznaczony dla aplikacji dla przedsiębiorstw. Te aplikacje często korzystają z wielu protokołów komunikacyjnych, mają różne kontrakty danych i wyższe wymagania dotyczące zabezpieczeń oraz mogą obejmować zarówno usługi w chmurze, jak i lokalne. Usługa Service Bus jest oparta na dedykowanej infrastrukturze obsługi komunikatów zaprojektowanej na potrzeby dokładnie tych scenariuszy.

Obie te usługi bazują na koncepcji kolejki, w której wysłane komunikaty są wstrzymywane, aż element docelowy będzie mógł je odebrać.

Co to są tematy usługi Azure Service Bus?

Tematy usługi Azure Service Bus są podobne do kolejek, ale mogą mieć wielu subskrybentów. Jeśli komunikat zostanie wysłany do tematu zamiast do kolejki, może to spowodować odpowiednie działanie wielu składników. Wyobraź sobie, że użytkownik słucha piosenki w aplikacji do udostępniania muzyki. Aplikacja mobilna może wysłać komunikat do tematu „Listened”. Ten temat będą subskrybować funkcje „UpdateUserListenHistory” i „UpdateArtistsFanList”, każda z nich posługująca się własną subskrypcją. Każda z tych funkcji jest obsługiwana przez inny składnik, który otrzyma własną kopię komunikatu.

Wewnętrznie tematy używają kolejek. Gdy opublikujesz do tematu, komunikatu zostanie skopiowany i umieszczony w kolejce dla każdej subskrypcji. Kolejka oznacza, że kopiowanie komunikatu pozostaje w pobliżu, aby były przetwarzane przez każdą gałąź subskrypcji, nawet jeśli składnik przetwarzający subskrypcję jest zbyt zajęty, aby nadążyć.

Korzyści z kolejek

Infrastruktura kolejek może obsługiwać wiele zaawansowanych funkcji, które sprawiają, że są przydatne w następujący sposób:

Większa niezawodność

Kolejki są używane przez aplikacje rozproszone jako tymczasowa lokalizacja magazynu na potrzeby komunikatów oczekujących na dostarczenie do składnika docelowego. Składnik źródłowy może dodać komunikat do kolejki, a składniki docelowe mogą pobrać komunikat znajdujący się na początku kolejki w celu przetworzenia. Kolejki zwiększają niezawodność wymiany komunikatów, ponieważ podczas wysokich obciążeń komunikaty można wstrzymać, aż składnik docelowy będzie gotowy je przetworzyć.

Gwarancje dostarczania komunikatów

Systemy kolejkowania zwykle gwarantują dostarczanie każdego komunikatu w kolejce do składnika docelowego. Jednak te gwarancje mogą korzystać z różnych podejść:

  • Co najmniej jednokrotne dostarczanie: w tym podejściu każdy komunikat ma gwarancję dostarczenia do co najmniej jednego ze składników pobierających komunikaty z kolejki. Należy jednak pamiętać, że w pewnych okolicznościach możliwe jest, że ten sam komunikat może zostać dostarczony więcej niż raz. Jeśli na przykład istnieją dwa wystąpienia aplikacji internetowej pobierającej komunikaty z kolejki, zazwyczaj każdy komunikat przechodzi tylko do jednego z tych wystąpień. Jeśli jednak przetworzenie komunikatu przez jedno wystąpienie trwa długo, a przekroczenie limitu czasu wygaśnie, komunikat może zostać również wysłany do drugiego wystąpienia. Należy pamiętać o tej możliwości, projektując kod aplikacji internetowej.

  • Co najwyżej jednokrotne dostarczanie: w tym podejściu każdy komunikat nie jest gwarantowany do dostarczenia i istnieje niewielkie prawdopodobieństwo, że nie zostanie dostarczony. Jednak w przeciwieństwie do dostarczania co najmniej jednokrotne, nie ma szans, aby komunikat został dostarczony dwa razy. Jest to czasami określane jako automatyczne wykrywanie duplikatów.

  • Pierwszy na wyjściu (FIFO): W większości systemów obsługi komunikatów komunikaty zwykle opuszczają kolejkę w tej samej kolejności, w jakiej zostały dodane, ale należy rozważyć, czy to dostarczanie jest gwarantowane. Jeśli aplikacja rozproszona wymaga, aby komunikaty były przetwarzane dokładnie w prawidłowej kolejności, należy wybrać system kolejki, który oferuje gwarancję FIFO.

Obsługa transakcyjna

Niektóre ściśle powiązane grupy komunikatów mogą powodować problemy, gdy dostarczanie zakończy się niepowodzeniem dla jednego komunikatu w grupie.

Rozważmy na przykład aplikację handlu elektronicznego. Gdy użytkownik wybierze przycisk Kup , może zostać wygenerowana seria komunikatów i wysłana do różnych miejsc docelowych przetwarzania:

  • Komunikat ze szczegółami zamówienia jest wysyłany do centrum realizacji zamówień.
  • Wiadomość z sumą i szczegółami płatności jest wysyłana do procesora kart kredytowych
  • Komunikat z informacją o potwierdzeniu jest wysyłany do bazy danych w celu wygenerowania faktury dla klienta

W tym przypadku chcemy upewnić się, że zostaną przetworzone wszystkie komunikaty lub nie zostaną przetworzone żadne z nich. Nie będziemy długo w firmie, jeśli wiadomość o karcie kredytowej nie zostanie dostarczona i wszystkie nasze zamówienia zostaną zrealizowane bez płatności! Aby uniknąć problemów tego typu można zgrupować dwa komunikaty jako transakcję. Transakcje komunikatów kończą się powodzeniem lub niepowodzeniem jako pojedyncza jednostka, podobnie jak w świecie bazy danych. Jeśli nie uda się dostarczyć komunikatu ze szczegółami karty kredytowej, komunikat ze szczegółami zamówienia również nie zostanie dostarczony.

Którą usługę mam wybrać?

Po zrozumieniu, że strategia komunikacji dla tej architektury powinna być komunikatem, należy wybrać, czy używać kolejek usługi Azure Storage, czy usługi Azure Service Bus. Obie technologie umożliwiają przechowywanie i dostarczanie komunikatów między składnikami. Każdy z nich ma nieco inny zestaw funkcji, co oznacza, że możesz wybrać jeden lub drugi albo użyć obu, w zależności od rozwiązywanego problemu.

Skorzystaj z kolejek usługi Service Bus, jeśli:

  • potrzebujesz gwarancji co najwyżej jednokrotnego dostarczania;
  • Potrzebujesz gwarancji FIFO.
  • Należy pogrupować komunikaty w transakcje.
  • Chcesz odbierać komunikaty bez sondowania kolejki.
  • chcesz udostępnić model dostępu opartego na rolach do kolejek;
  • Należy obsługiwać komunikaty większe niż 64 KB, ale mniej niż 100 MB. Maksymalny rozmiar komunikatu obsługiwany przez warstwę Standardowa to 256 KB, a warstwa Premium to 100 MB.
  • Rozmiar kolejki nie będzie większy niż 1 TB. Maksymalny rozmiar kolejki dla warstwy Standardowa wynosi 80 GB, a warstwa Premium wynosi 1 TB.
  • chcesz mieć możliwość publikowania i używania partii komunikatów.

Skorzystaj z tematów usługi Service Bus, jeśli:

  • Potrzebujesz wszystkich funkcji udostępnianych przez kolejki usługi Service Bus, a ponadto zaimplementuj wzorzec pub-sub, w którym komunikaty mogą być kierowane do jednej z wielu subskrypcji, z których każdy ma własne niezależne odbiorniki

Usługa Queue Storage nie ma tak rozbudowanych możliwości, ale może być lepszym wyborem, jeśli nie potrzebujesz bardziej zaawansowanych funkcji. Ponadto jest najlepszym rozwiązaniem, jeśli aplikacja ma dowolne z poniższych wymagań.

Skorzystaj z usługi Queue Storage, jeśli:

  • potrzebujesz dziennika inspekcji dla wszystkich komunikatów przechodzących przez kolejkę;
  • Spodziewaj się, że rozmiar kolejki przekroczy 1 TB.
  • chcesz śledzić postęp przetwarzania komunikatów w kolejce.

Kolejka to prosta, tymczasowa lokalizacja magazynu na potrzeby komunikatów wysyłanych między składnikami aplikacji rozproszonej. Kolejka służy do organizowania komunikatów i bezproblemowej obsługi nieprzewidywalnych wzrostów zapotrzebowania.

Kolejek usługi Storage można użyć, jeśli system kolejek ma być prosty i łatwy do kodowania. W przypadku bardziej zaawansowanych potrzeb należy używać kolejek usługi Service Bus. Jeśli każdy komunikat ma wiele miejsc docelowych, lecz potrzebujesz zachowania kolejek, użyj tematów usługi Service Bus.