Wzorce asynchronicznej obsługi komunikatów i wysoka dostępność

Asynchroniczne komunikaty można zaimplementować na różne sposoby. W przypadku kolejek, tematów i subskrypcji Azure Service Bus obsługuje asynchronizm za pośrednictwem mechanizmu magazynu i przekazywania dalej. W normalnej (synchronicznej) operacji wysyłasz komunikaty do kolejek i tematów oraz odbierasz komunikaty z kolejek i subskrypcji. Aplikacje, które piszesz, zależą od tych jednostek, które są zawsze dostępne. Gdy kondycja jednostki ulegnie zmianie ze względu na różne okoliczności, musisz zapewnić ograniczoną jednostkę możliwości, która może zaspokoić większość potrzeb.

Aplikacje zwykle używają wzorców asynchronicznych obsługi komunikatów w celu włączenia wielu scenariuszy komunikacji. Można tworzyć aplikacje, w których klienci mogą wysyłać komunikaty do usług, nawet jeśli usługa nie jest uruchomiona. W przypadku aplikacji, które doświadczają serii komunikacji, kolejka może pomóc wyrównać obciążenie , zapewniając miejsce do buforowania komunikacji. Na koniec możesz uzyskać prosty, ale skuteczny moduł równoważenia obciążenia do dystrybucji komunikatów na wielu maszynach.

Aby zachować dostępność dowolnej z tych jednostek, należy wziąć pod uwagę różne sposoby, w jaki te jednostki mogą wydawać się niedostępne dla trwałego systemu obsługi komunikatów. Ogólnie rzecz biorąc, widzimy, że jednostka staje się niedostępna dla aplikacji, które piszemy na następujące sposoby:

• Nie można wysłać wiadomości.
• Nie można odebrać komunikatów.
• Nie można zarządzać jednostkami (tworzenie, pobieranie, aktualizowanie lub usuwanie jednostek).
• Nie można skontaktować się z usługą.

Dla każdego z tych błędów istnieją różne tryby awarii, które umożliwiają aplikacji kontynuowanie pracy na pewnym poziomie ograniczonej możliwości. Na przykład system, który może wysyłać komunikaty, ale nie odbierać ich, nadal może odbierać zamówienia od klientów, ale nie może przetworzyć tych zamówień. W tym temacie omówiono potencjalne problemy, które mogą wystąpić, oraz sposób ich rozwiązywania. Usługa Service Bus wprowadziła szereg środków zaradczych, które należy zastosować, a w tym temacie omówiono również zasady dotyczące korzystania z tych środków zaradczych.

Niezawodność w usłudze Service Bus

Istnieje kilka sposobów obsługi problemów z komunikatami i jednostkami, a istnieją wytyczne dotyczące odpowiedniego stosowania tych środków zaradczych. Aby zrozumieć wytyczne, musisz najpierw zrozumieć, co może zakończyć się niepowodzeniem w usłudze Service Bus. Ze względu na projektowanie systemów platformy Azure wszystkie te problemy są zwykle krótkotrwałe. Na wysokim poziomie różne przyczyny niedostępności są następujące:

• Ograniczanie przepustowości z systemu zewnętrznego, od którego zależy usługa Service Bus. Ograniczanie przepływności występuje z interakcji z magazynem i zasobami obliczeniowymi.
• Problem dotyczący systemu, od którego zależy usługa Service Bus. Na przykład dana część magazynu może napotkać problemy.
• Awaria usługi Service Bus w pojedynczym podsystemie. W takiej sytuacji węzeł obliczeniowy może przechodzić w niespójny stan i musi zostać uruchomiony ponownie, powodując, że wszystkie jednostki, które służy do równoważenia obciążenia do innych węzłów. To z kolei może spowodować krótki okres powolnego przetwarzania komunikatów.
• Awaria usługi Service Bus w centrum danych platformy Azure. Jest to "katastrofalna awaria", podczas której system jest niedostępny przez wiele minut lub kilka godzin.

Uwaga

Termin magazyn może oznaczać zarówno usługę Azure Storage, jak i Usługi SQL Azure.

Usługa Service Bus zawiera szereg środków zaradczych związanych z tymi problemami. W poniższych sekcjach omówiono poszczególne problemy i ich odpowiednie środki zaradcze.

Ograniczanie przepływności

Dzięki usłudze Service Bus ograniczanie umożliwia kooperatywne zarządzanie szybkością komunikatów. Każdy węzeł usługi Service Bus zawiera wiele jednostek. Każda z tych jednostek sprawia, że wymagania dotyczące systemu są zależne od procesora CPU, pamięci, magazynu i innych aspektów. Jeśli którykolwiek z tych aspektów wykryje użycie przekraczające zdefiniowane progi, usługa Service Bus może odmówić danego żądania. Obiekt wywołujący otrzymuje wyjątek zajęty serwera i ponawia próbę po 10 sekundach.

Aby zaradczeć, kod musi odczytać błąd i zatrzymać wszelkie ponawianie próby komunikatu przez co najmniej 10 sekund. Ponieważ błąd może wystąpić w różnych częściach aplikacji klienta, oczekuje się, że każdy element niezależnie wykonuje logikę ponawiania. Kod może zmniejszyć prawdopodobieństwo ograniczenia przepustowości, włączając partycjonowanie w przestrzeni nazw, kolejce lub temacie.

Aby uzyskać więcej informacji na temat sposobu obsługi problemów z ograniczaniem przepustowości w kodzie aplikacji, zobacz dokumentację dotyczącą wzorca ograniczania przepustowości.

Problem dotyczący zależności platformy Azure

Inne składniki na platformie Azure mogą czasami mieć problemy z usługą. Na przykład po uaktualnieniu systemu używanego przez usługę Service Bus system może tymczasowo zmniejszyć możliwości. Aby obejść tego typu problemy, usługa Service Bus regularnie bada i implementuje środki zaradcze. Pojawiają się skutki uboczne tych środków zaradczych. Na przykład w celu obsługi przejściowych problemów z magazynem usługa Service Bus implementuje system, który umożliwia spójne działanie operacji wysyłania komunikatów. Ze względu na charakter ograniczania ryzyka wysłany komunikat może pojawić się w kolejce lub subskrypcji, której dotyczy problem, może upłynąć do 15 minut i być gotowy do wykonania operacji odbierania. Ogólnie rzecz biorąc, większość jednostek nie napotka tego problemu. Jednak biorąc pod uwagę liczbę jednostek w usłudze Service Bus na platformie Azure, to ograniczenie ryzyka jest czasami konieczne dla małego podzbioru klientów usługi Service Bus.

Awaria usługi Service Bus w jednym podsystemie

W przypadku każdej aplikacji sytuacja może spowodować, że wewnętrzny składnik usługi Service Bus stanie się niespójny. Gdy usługa Service Bus wykryje to, zbiera dane z aplikacji, aby pomóc w diagnozowaniu tego, co się stało. Po zebraniu danych aplikacja zostanie ponownie uruchomiona, próbując przywrócić je do spójnego stanu. Ten proces odbywa się dość szybko i powoduje, że jednostka wydaje się być niedostępna przez maksymalnie kilka minut, chociaż typowe czasy przestoju są znacznie krótsze.

W takich przypadkach aplikacja kliencka generuje wyjątek limitu czasu lub wyjątek obsługi komunikatów. Usługa Service Bus zawiera środki zaradcze dla tego problemu w postaci zautomatyzowanej logiki ponawiania prób klienta. Po wyczerpaniu okresu ponawiania i nie dostarczaniu komunikatu możesz użyć innych informacji wymienionych w artykule dotyczącym obsługi awarii i awarii.

Następne kroki

Teraz, gdy znasz już podstawy asynchronicznej obsługi komunikatów w usłudze Service Bus, przeczytaj więcej szczegółów na temat obsługi awarii i awarii.