Udostępnij za pomocą

Styl architekturyQueue-Worker sieci Web

Podstawowe składniki tej architektury to fronton internetowy , który obsługuje żądania klientów i proces roboczy , który wykonuje zadania intensywnie korzystające z zasobów, długotrwałe przepływy pracy lub zadania wsadowe. Fronton internetowy komunikuje się z procesem roboczym za pośrednictwem kolejki komunikatów.

Diagram logiczny przedstawiający architekturę Web-Queue-Worker.

Następujące składniki są często uwzględniane w tej architekturze:

  • Co najmniej jedna baza danych

  • Pamięć podręczna do przechowywania wartości z bazy danych w celu szybkiego odczytu

  • Sieć dostarczania zawartości do obsługi zawartości statycznej

  • Usługi zdalne, takie jak poczta e-mail lub krótka usługa wiadomości (SMS), które zwykle udostępniają dostawcy usług innych niż Microsoft

  • Dostawca tożsamości na potrzeby uwierzytelniania

Sieć Web i proces roboczy są bezstanowe, a stan sesji można przechowywać w rozproszonej pamięci podręcznej. Pracownik obsługuje długotrwałą pracę asynchronicznie. Komunikaty w kolejce mogą uruchamiać pracownika, lub harmonogram może go uruchomić na potrzeby przetwarzania wsadowego. Wątek roboczy jest opcjonalny, jeśli aplikacja nie zawiera długotrwałych operacji.

Frontend może zawierać internetowy interfejs API. Aplikacja jednostronicowa może korzystać z internetowego interfejsu API, wykonując wywołania AJAX lub natywna aplikacja kliencka może używać go bezpośrednio.

Kiedy należy używać tej architektury

Architektura Web-Queue-Worker jest zwykle implementowana przy użyciu zarządzanych usług obliczeniowych, takich jak Azure App Service lub Azure Kubernetes Service.

Rozważ tę architekturę dla następujących przypadków użycia:

  • Aplikacje, które mają stosunkowo prostą domenę

  • Aplikacje, które mają długotrwałe procesy robocze lub operacje wsadowe

  • Scenariusze, w których preferowane są usługi zarządzane zamiast infrastruktury jako usługi (IaaS)

Korzyści

  • Architektura, która jest prosta i łatwa do naśladowania

  • Wdrażanie i zarządzanie przy minimalnym nakładzie pracy

  • Jasne rozdzielenie obowiązków

  • Oddzielenie frontonu i procesu roboczego za pomocą asynchronicznych komunikatów

  • Niezależne skalowanie frontonu i procesu roboczego

Wyzwania

  • Bez starannego projektowania fronton i proces roboczy mogą stać się dużymi składnikami monolitycznymi, które są trudne do utrzymania i aktualizacji.

  • Jeśli fronton i proces roboczy udostępniają schematy danych lub moduły kodu, mogą istnieć ukryte zależności.

  • Interfejs webowy może zakończyć się niepowodzeniem po zapisaniu do bazy danych, ale przed wysłaniem komunikatów do kolejki, co powoduje problemy ze spójnością, ponieważ pracownik nie realizuje swojej części logiki. Aby rozwiązać ten problem, możesz użyć technik, takich jak wzorzec transakcyjnej skrzynki nadawczej, które wymagają przepuszczania komunikatów wychodzących przez oddzielną kolejkę przed ich wysłaniem dalej. Biblioteka sesji transakcyjnej NServiceBus obsługuje tę technikę.

Najlepsze rozwiązania

Web Queue-Worker w usłudze App Service

W tej sekcji opisano zalecaną architekturę Web-Queue-Worker używającą usługi App Service.

Diagram przedstawiający architekturęQueue-Worker sieci Web.

Pobierz plik programu Visio tej architektury.

Workflow

  • Front-end jest implementowany jako aplikacja sieciowa App Service, a proces roboczy jest implementowany jako aplikacja funkcji Azure Functions. Aplikacja internetowa i aplikacja Functions są skojarzone z planem usługi App Service, który udostępnia wystąpienia maszyn wirtualnych.

  • Można użyć albo Azure Service Bus, albo Azure Storage queues do obsługi kolejki komunikatów. Na poprzednim diagramie jest używana kolejka usługi Storage.

  • Usługa Azure Managed Redis przechowuje stan sesji i inne dane, które wymagają dostępu o małych opóźnieniach.

  • Usługa Azure Content Delivery Network służy do buforowania zawartości statycznej, takiej jak obrazy, CSS lub HTML.

  • W przypadku przechowywania wybierz technologie, które najlepiej odpowiadają potrzebom aplikacji. Takie podejście, znane jako trwałość poliglotyczna, używa wielu technologii magazynowania w tym samym systemie, aby sprostać różnym wymaganiom. Aby zilustrować ten pomysł, diagram przedstawia zarówno usługę Azure SQL Database , jak i usługę Azure Cosmos DB.

Aby uzyskać więcej informacji, zobacz Szablin wysoce dostępnej, strefowo nadmiarowej aplikacji internetowej i Tworzenie aplikacji biznesowych opartych na komunikatach za pomocą NServiceBus i Azure Service Bus.

Inne uwagi

  • Nie każda transakcja musi przechodzić przez kolejkę i proces roboczy do magazynu. Fronton internetowy może wykonywać proste operacje odczytu i zapisu bezpośrednio. Pracownicy są przeznaczeni do zadań wymagających intensywnego korzystania z zasobów lub do długotrwałych przepływów pracy. W niektórych przypadkach może w ogóle nie być potrzebny pracownik.

  • Użyj wbudowanej funkcji automatycznego skalowania platformy obliczeniowej, aby zwiększyć liczbę wystąpień. Jeśli obciążenie aplikacji jest zgodne z przewidywalnymi wzorcami, użyj skalowania automatycznego opartego na harmonogramie. Jeśli obciążenie jest nieprzewidywalne, użyj autoskalowania opartego na metrykach.

  • Rozważ umieszczenie aplikacji internetowej i aplikacji usługi Functions w oddzielnych planach usługi App Service, aby umożliwić niezależne skalowanie.

  • Użyj oddzielnych planów usługi App Service na potrzeby produkcji i testowania.

  • Użyj miejsc wdrożenia do zarządzania wdrożeniami. Ta metoda umożliwia wdrożenie zaktualizowanej wersji w miejscu przejściowym, a następnie zamianę na nową wersję. Umożliwia również zamianę z powrotem na poprzednią wersję, jeśli wystąpi problem podczas aktualizacji.

  • Last updated on