Styl architekturyQueue-Worker sieci Web

Ta architektura ma dwa podstawowe składniki. Interfejs webowy obsługuje żądania klientów, a silnik roboczy wykonuje zadania intensywnie korzystające z zasobów, długotrwałe procesy robocze lub zadania wsadowe. Fronton internetowy komunikuje się z procesem roboczym za pośrednictwem kolejki komunikatów.

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

Ta architektura zwykle używa następujących składników:

  • 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

Fronton internetowy i proces roboczy są bezstanowe. Stan sesji można przechowywać w rozproszonej pamięci podręcznej. Pracownik obsługuje długotrwałą pracę asynchronicznie. Pracownika można wyzwolić przy użyciu komunikatów w kolejce lub uruchomić go według harmonogramu dla 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 przez asynchroniczne żądania HTTP lub natywna aplikacja kliencka może korzystać bezpośrednio z niego.

Kiedy należy używać tej architektury

Aby zaimplementować architekturę web-Queue-Worker, zazwyczaj używasz zarządzanych usług obliczeniowych, takich jak Azure App Service, Azure Kubernetes Service (AKS) lub Azure Container Apps.

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

  • Prosta architektura, która jest łatwa do zrozumienia

  • Proste wdrażanie i zarządzanie

  • Jasne rozdzielenie obowiązków między interfejsem użytkownika a zadaniem roboczym

  • Asynchroniczne wiadomości, które oddzielają front-end od workera

  • Możliwość niezależnego skalowania frontonu i procesu roboczego

Wyzwania

  • Bez starannego projektowania frontend oraz worker mogą rozwijać się w duże komponenty monolityczne, które stają się trudne do utrzymania i aktualizacji.

  • Udostępnione schematy danych lub moduły kodu między front-endem a workerem mogą tworzyć ukryte zależności.

  • Interfejs webowy może ulegać awarii po zapisaniu danych w bazie, ale przed wysłaniem komunikatu do kolejki. Ten błąd powoduje problemy ze spójnością, ponieważ proces roboczy nigdy nie przetwarza swojej części logiki. Aby rozwiązać ten problem, użyj technik, takich jak wzorzec transakcyjnej skrzynki odbiorczej, który najpierw kieruje komunikaty wychodzące przez oddzielną kolejkę. Biblioteka sesji transakcyjnej NServiceBus obsługuje to podejście.

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

  • Aplikacja internetowa App Service służy jako interfejs użytkownika, a aplikacja Azure Functions działa jako usługa robocza. Oba składniki działają w ramach planu usługi App Service.

  • Diagram ilustruje implementację, która używa Azure Queue Storage. Możesz również użyć Azure Service Bus jako kolejki komunikatów, w zależności od wymagań dotyczących obsługi komunikatów.

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

  • Dzięki włączonej pamięci podręcznej Azure Front Door Standard lub Premium buforuje zawartość statyczną, na przykład obrazy, arkusze CSS i HTML z Azure Blob Storage.

  • W przypadku przechowywania danych wybierz technologie, które najlepiej pasują do potrzeb aplikacji. Takie podejście, znane jako trwałość poliglotyczna, łączy wiele technologii magazynowania w jednym systemie w celu spełnienia różnych wymagań. Na poprzednim diagramie przedstawiono to podejście przy użyciu usług Azure SQL Database i Azure Cosmos DB.

Aby uzyskać więcej informacji, zobacz Bazowa wysoce dostępna aplikacja internetowa redundantna strefowo oraz Tworzenie aplikacji biznesowych opartych na komunikatach przy użyciu NServiceBus i Service Bus.

Inne uwagi

  • Nie każda transakcja musi przechodzić przez kolejkę i proces roboczy do magazynu. Fronton internetowy może obsługiwać proste operacje odczytu i zapisu bezpośrednio. Rezerwuj pracowników do zadań wymagających intensywnego wykorzystania zasobów lub długotrwałych przepływów pracy. Jeśli aplikacja nie ma takich zadań, być może nie potrzebujesz procesu roboczego.

  • Użyj wbudowanej funkcji automatycznego skalowania platformy obliczeniowej, aby rozszerzać poziomo instancje. Jeśli obciążenie 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 dla środowisk produkcyjnych i testowych.

  • Użyj slotów wdrożeniowych do zarządzania wdrożeniami planów usługi App Service. Wdróż zaktualizowaną wersję w środowisku testowym, a następnie przełącz na nową wersję. Jeśli wystąpią problemy, zamień z powrotem na poprzednią wersję.

  • Ostatnia aktualizacja o