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 usługa 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 tego, czy te jednostki 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, aby umożliwić wiele scenariuszy komunikacji. Możesz 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ą pęknięć komunikacji, kolejka może pomóc w wyrównaniu obciążenia , zapewniając miejsce do buforowania komunikacji. Na koniec możesz uzyskać prosty, ale skuteczny moduł równoważenia obciążenia w celu dystrybucji komunikatów między wieloma maszynami.

Aby zachować dostępność dowolnej z tych jednostek, należy wziąć pod uwagę wiele różnych sposobów, 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 dalsze wykonywanie 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 rozwiązywania tych problemów. Usługa Service Bus wprowadziła szereg środków zaradczych, które należy wyrazić, a w tym temacie omówiono również zasady dotyczące stosowania 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 projekt systemów platformy Azure wszystkie te problemy wydają się być krótkotrwałe. Na wysokim poziomie różne przyczyny niedostępności pojawiają się w następujący sposób:

• 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 przejść do niespójnego stanu 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. Z kolei może to 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 storage może oznaczać zarówno usługę Azure Storage, jak i Usługi SQL Azure.

Usługa Service Bus zawiera szereg środków zaradczych dla tych problemów. 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 zarządzanie szybkością komunikatów współpracy. Każdy węzeł usługi Service Bus mieści wiele jednostek. Każda z tych jednostek wymaga użycia procesora CPU, pamięci, magazynu i innych aspektów. Jeśli którykolwiek z tych aspektów wykryje użycie, które przekracza 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.

Jako środki 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ść te typy problemów, 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. Mówiąc ogólnie, 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 podzestawu klientów usługi Service Bus.

Awaria usługi Service Bus w jednym podsystemie

W przypadku dowolnej aplikacji okoliczności mogą 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ę niedostępna przez maksymalnie kilka minut, choć typowe czasy przestoju są znacznie krótsze.

W takich przypadkach aplikacja kliencka generuje wyjątek przekroczenia 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. Gdy okres ponawiania prób zostanie wyczerpany i komunikat nie zostanie dostarczony, możesz zapoznać się z użyciem 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.