Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Użyj kolejki, która pełni funkcję bufora między zadaniem a usługą, którą ono wywołuje. Takie podejście zapobiega sporadycznie dużym obciążeniom, które mogą spowodować awarię usługi lub przekroczenie limitu czasu zadania. Pomaga zminimalizować wpływ szczytu zapotrzebowania na dostępność i czas odpowiedzi zadania i usługi.
Kontekst i problem
Wiele rozwiązań w chmurze uruchamia zadania, które wywołują usługi. W tym środowisku sporadyczne duże obciążenia mogą powodować problemy z wydajnością lub niezawodnością usługi.
Usługa może być częścią tego samego rozwiązania, co zadania, które go używają, lub może to być usługa partnerska, która zapewnia dostęp do często używanych zasobów. Przykłady tych typów usług obejmują pamięć podręczną lub usługę magazynu. Jeśli wiele zadań jest uruchamianych współbieżnie i używa tej samej usługi, trudno jest przewidzieć liczbę żądań w dowolnym momencie.
Usługa może napotkać szczyty zapotrzebowania, które ją przeciążą i sprawiają, że usługa nie może szybko odpowiadać na żądania. Zalewanie usługi dużą liczbą współbieżnych żądań może również doprowadzić do jej awarii, jeśli nie jest ona w stanie poradzić sobie z konkurencją o zasoby wywołaną przez te żądania.
Rozwiązanie
Umieść kolejkę między zadaniem a usługą. Zadania i usługi działają asynchronicznie. Zadanie wysyła do kolejki komunikat zawierający dane wymagane przez usługę. Kolejka działa jako bufor i przechowuje komunikat do momentu pobrania go przez usługę. Usługa pobiera wiadomości z kolejki i przetwarza je. Żądania z wielu zadań, generowane z bardzo zróżnicowaną częstotliwością, mogą być przekazywane do usługi za pośrednictwem tej samej kolejki komunikatów. Na poniższym diagramie pokazano, jak kolejka może wyrównać obciążenie usługi.
Kolejka oddziela zadania od usługi, dzięki czemu usługa może przetwarzać komunikaty we własnym tempie, nawet gdy współbieżne zadania generują dużą liczbę żądań. Ponadto zadania nie są opóźniane, jeśli usługa jest niedostępna w momencie wysyłania komunikatów do kolejki.
Ten wzorzec zapewnia następujące korzyści:
Pomaga zmaksymalizować dostępność, ponieważ opóźnienia usługi nie wpływają natychmiast i bezpośrednio na aplikację. Aplikacja może nadal wysyłać komunikaty do kolejki, nawet jeśli usługa jest niedostępna lub obecnie nie przetwarza komunikatów.
Pomaga zmaksymalizować skalowalność, ponieważ liczba kolejek i liczba usług mogą się różnić w zależności od zapotrzebowania.
Pomaga to kontrolować koszty, ponieważ potrzebujesz tylko wystarczającej liczby wystąpień usługi, aby spełnić wymagania dotyczące średniego obciążenia, a nie szczytowego obciążenia.
Uwaga / Notatka
Niektóre usługi implementują ograniczanie przepustowości, gdy zapotrzebowanie osiągnie próg, który może spowodować awarię systemu. Ograniczanie przepustowości może zmniejszyć dostępną funkcjonalność. Zaimplementuj bilansowanie obciążenia w tych usługach, aby upewnić się, że zapotrzebowanie nie osiągnie tego progu.
Problemy i zagadnienia
Podczas podejmowania decyzji o zaimplementowaniu tego wzorca należy wziąć pod uwagę następujące kwestie:
Zaimplementuj logikę aplikacji, która kontroluje szybkość obsługi komunikatów przez usługi, aby uniknąć przeciążenia zasobu docelowego. Należy unikać przekazywania nagłych skoków popytu na kolejny etap systemu. Przetestuj system pod obciążeniem, aby upewnić się, że zapewnia wymagane bilansowanie. Aby osiągnąć wymagane wyrównanie obciążenia, dostosuj liczbę kolejek oraz instancji usługi obsługujących komunikaty.
Kolejki komunikatów to mechanizm komunikacji jednokierunkowej. Jeśli zadanie oczekuje odpowiedzi z usługi, może być konieczne zaimplementowanie mechanizmu, którego usługa może użyć do wysłania odpowiedzi. Aby uzyskać więcej informacji, zobacz Opcje obsługi komunikatów asynchronicznych w Azure.
Skalowanie automatyczne bez ograniczenia zagregowanej szybkości podrzędnej odbiorców przenosi przeciążenie tylko do zależności podrzędnych. Takie przeciążenie może zwiększyć konkurencję o zasoby współdzielone przez te usługi i zmniejszyć skuteczność kolejki w równoważeniu obciążenia.
Jeśli średni wskaźnik producenta przekracza wskaźnik konsumentów, kolejka nadal rośnie i zwiększa się opóźnienie. Monitoruj głębokość kolejki i skaluj konsumentów w bezpiecznych granicach albo ogranicz obciążenie po stronie producenta.
Ten wzorzec zależy od trwałości kolejki, aby zapobiec utracie komunikatów. Jeśli broker nie utrwala komunikatów w trwałej pamięci masowej, awaria lub ograniczenie pojemności mogą spowodować utratę danych umieszczonych w kolejce, zanim zostaną przetworzone przez konsumentów. Wybierz usługę kolejkowania, która zapisuje komunikaty na dysku lub w magazynie replikowanym, i poznaj limity rozmiaru oraz limity czasu przechowywania. W przypadku obciążeń wymagających komunikatów do przetrwania awarii regionalnych należy ocenić opcje odzyskiwania po awarii geograficznej.
Większość usług kolejkowania dostarcza komunikaty z gwarancją co najmniej jednokrotnego dostarczenia, co oznacza, że odbiorcy mogą otrzymać ten sam komunikat więcej niż raz. Zaprojektuj logikę konsumenta jako idempotentną , tak aby przetwarzanie tego samego komunikatu wiele razy generuje ten sam wynik i pozwala uniknąć problemów, takich jak zduplikowane rekordy lub powtarzające się opłaty.
Nie można przetworzyć niektórych komunikatów, ponieważ zawierają one nieprawidłowo sformatowane dane, odwołują się do brakujących zasobów lub powodują utrzymujące się błędy. Zamiast pozwalać tym komunikatom krążyć w nieskończoność i blokować kolejkę, należy przekierować je do kolejki martwych wiadomości. Monitoruj głębokość kolejki utraconych komunikatów, aby zespół operacyjny mógł badać błędy, rozwiązywać podstawowy problem i przesyłać ponownie komunikaty w razie potrzeby.
Dodanie kolejki między producentem a konsumentem nie zachowuje pierwotnej kolejności przesyłania w każdych warunkach, zwłaszcza gdy wielu konsumentów przetwarza komunikaty równolegle. Jeśli obciążenie robocze wymaga ścisłej kolejności, użyj funkcji, takich jak sesje komunikatów w Azure Service Bus. Jeśli nie jest wymagane ścisłe porządkowanie, należy zaprojektować użytkowników, aby obsługiwali komunikaty w dowolnej kolejności, co upraszcza skalowanie.
Kiedy należy używać tego wzorca
Użyj tego wzorca, gdy:
Twoje obciążenie doświadcza okresowych skoków, które mogą przeciążać usługi podrzędne.
Należy rozdzielić pobieranie żądań od przepływności przetwarzania, aby zwiększyć odporność i kontrolę kosztów.
Ten wzorzec może nie być odpowiedni w następujących przypadkach:
Element wywołujący wymaga synchronicznej odpowiedzi o niskim opóźnieniu.
Wolumin obciążenia jest przewidywalnie niski i stabilny, dlatego dodanie złożoności kolejkowania zapewnia niewielką korzyść.
Projektowanie obciążenia pracy
Oceń, jak zastosować wzorzec równoważenia obciążenia oparty na kolejce w projekcie obciążenia roboczego, aby zrealizować cele i zasady omówione w filarach Azure Well-Architected Framework. Poniższa tabela zawiera wskazówki dotyczące tego, jak ten wzorzec obsługuje cele poszczególnych filarów.
| Filar | Jak ten wzorzec obsługuje cele filaru |
|---|---|
| Decyzje projektowe dotyczące niezawodności pomagają obciążeniom stały się odporne na awarię i zapewniają, że zostanie ono przywrócone do w pełni funkcjonalnego stanu po wystąpieniu awarii. | Podejście opisane przez ten wzorzec może zapewnić odporność na nagłe skoki obciążenia poprzez oddzielenie napływu zadań od ich przetwarzania. Może również odizolować awarie przetwarzania kolejek, aby nie wpływały na przetwarzanie wejściowe. - RE:06 Skalowanie |
| Optymalizacja kosztów koncentruje się na utrzymaniu i poprawiezwrotu obciążenia z inwestycji. | Ponieważ przetwarzanie obciążenia jest oddzielone od żądania lub wprowadzania zadań, można użyć tego podejścia, aby zmniejszyć potrzebę nadmiernej aprowizacji zasobów w celu obsługi szczytowego obciążenia. - CO:12 Koszty skalowania |
| Efektywność wydajności pomaga wydajnie sprostać wymaganiom dzięki optymalizacjom skalowania, danych i kodu. | Takie podejście umożliwia zamierzone projektowanie wydajności przepływności, ponieważ pobieranie żądań nie musi być skorelowane z szybkością przetwarzania. - PE:05 Skalowanie i partycjonowanie |
Jeśli ten wzorzec wprowadza kompromisy w ramach filaru, rozważ je przed celami innych filarów.
Example
Aplikacja internetowa zapisuje dane w zewnętrznym magazynie danych. Jeśli kilka wystąpień aplikacji internetowej działa jednocześnie, magazyn danych może nie być w stanie odpowiadać na żądania wystarczająco szybko, przez co żądania przekraczają limit czasu, są ograniczane lub w inny sposób kończą się niepowodzeniem. Poniższy diagram pokazuje magazyn danych przeciążony współbieżnymi żądaniami pochodzącymi z instancji aplikacji.
Aby rozwiązać ten problem, użyj kolejki, aby wyrównać obciążenie między wystąpieniami aplikacji a magazynem danych. Aplikacja Azure Functions odczytuje komunikaty z kolejki Service Bus i wykonuje żądania odczytu/zapisu do magazynu danych. Liczbę wystąpień usługi Azure Functions można skalować na podstawie zaległości komunikatów w usłudze Service Bus przy użyciu skalowania opartego na obiektach docelowych, w granicach skonfigurowanych limitów skalowania. Możesz również dostroić ustawienia współbieżności wyzwalacza, aby chronić magazyn danych. Aby uzyskać wskazówki dotyczące wdrożenia, zobacz Skalowanie oparte na celu i Ograniczanie skalowania w poziomie. Bez tego dostrojenia warstwa procesów roboczych może ponownie wprowadzić rywalizację o zasoby zaplecza.
Jako odmiana technologii można zaimplementować ten sam wzorzec przy użyciu Azure Container Apps zamiast Azure Functions. W tym podejściu proces roboczy działający w kontenerze odbiera komunikaty z Service Bus i zapisuje dane w magazynie danych. Usługa Container Apps skaluje proces roboczy w zakresie od skonfigurowanej minimalnej do maksymalnej liczby replik na podstawie reguł skalowania związanych z kolejką. Można również zaimplementować to samo podejście przy użyciu Azure Queue Storage co źródło zdarzenia. Aby uzyskać wskazówki dotyczące implementacji, zobacz Ustawianie reguł skalowania w usłudze Container Apps i Wdrażanie zadania sterowanego zdarzeniami przy użyciu usługi Container Apps.
Następne kroki
Następujące wskazówki mogą być również istotne podczas implementowania tego wzorca:
Opcje asynchronicznej obsługi komunikatów w Azure: Kolejki komunikatów są z natury asynchroniczne. Może być konieczne przeprojektowanie logiki aplikacji zadania, jeśli komunikuje się bezpośrednio z usługą. Podobnie może być konieczna refaktoryzacja usługi tak, aby przyjmowała żądania z kolejki komunikatów.
Wybierz między usługami komunikatów platformy Azure: Uzyskaj więcej informacji, które pomogą Ci wybrać mechanizm obsługi komunikatów i kolejkowania w aplikacjach platformy Azure.
Zalecenia dotyczące tworzenia zadań w tle: zastosuj ten wzorzec do zadań w tle, aby kolejki komunikatów mogły przechowywać żądania zadań w tle, gdy aplikacja ma duże obciążenie.
Styl architektury Web-Queue-Worker: aplikacja internetowa i proces roboczy są bezstanowe. Stan sesji można przechowywać w rozproszonej pamięci podręcznej. Proces roboczy wykonuje długotrwałe zadania asynchronicznie i może być wyzwalany przez komunikaty w kolejce lub uruchamiany zgodnie z harmonogramem na potrzeby przetwarzania wsadowego.
Powiązane zasoby
Wzorzec konkurujących odbiorców: może być możliwe uruchomienie wielu wystąpień usługi, z których każdy działa jako odbiorca komunikatów z kolejki bilansowania obciążenia. Takie podejście umożliwia dostosowanie szybkości, z jaką usługa odbiera i przekazuje komunikaty.
Wzorzec ograniczania przepustowości: prostym sposobem zaimplementowania ograniczania przepustowości w usłudze jest użycie bilansowania obciążenia opartego na kolejce i kierowanie wszystkich żądań do usługi za pośrednictwem kolejki komunikatów. Usługa może przetwarzać żądania w tempie, co gwarantuje, że nie wyczerpa zasobów, których potrzebuje, i zmniejsza ilość możliwych rywalizacji.